SOC 2 & ISO 27001: Audit-Bereitschaft für selbst gehostete LLMs (2026)

Nein — dieser Leitfaden ist keine Rechts- oder Compliance-Beratung. Er erklärt auf technischer Ebene, welche Kontrollkategorien ein SOC-2- oder ISO-27001-Auditor typischerweise prüft und wie sie sich auf ein selbst gehostetes LLM-Deployment abbilden lassen. Ob eine konkrete Kontrolle Ihr Audit erfüllt, hängt vom Urteil Ihres Auditors, der Risikobewertung Ihrer Organisation und dem genauen Scope-Statement ab, das Sie einreichen. Konsultieren Sie einen qualifizierten Auditor, QSA oder Ihre Compliance-Abteilung, bevor Sie ein Audit planen oder Compliance-Aussagen treffen.

SOC 2 bewertet eine Organisation anhand von fünf Trust Services Criteria (TSC), und jedes davon gilt für ein selbst gehostetes LLM-System, sobald es Produktivdaten berührt. Ein Auditor testet nicht das Modell — er testet, ob Ihre Organisation nachweisen kann, dass die Kontrolle über den Prüfzeitraum existierte und funktionierte.

Nutzen Sie Sicherheit, wenn Ihr Bericht nur das Basiskriterium abdecken muss (verpflichtend in jedem SOC-2-Bericht). Ergänzen Sie Verfügbarkeit, wenn das LLM einen Produktiv-Workflow mit Verfügbarkeitszusage bedient. Ergänzen Sie Vertraulichkeit, wenn Prompts oder Ausgaben vertraglich geschützte Daten enthalten.

ISO 27001 zertifiziert das Informationssicherheits-Managementsystem (ISMS) einer Organisation, und Annex A ist die Referenzliste der Kontrollen, aus denen das ISMS schöpft — keine direkt auf ein einzelnes System angewandte Checkliste. Ein selbst gehostetes LLM-Deployment liegt wie jeder andere Asset im ISMS-Geltungsbereich: es braucht eine Risikobewertung, einen Eintrag in der Statement of Applicability und Nachweise, dass die relevanten Kontrollen funktionieren.

Nutzen Sie zuerst die organisatorischen Kontrollen (A.5) — sie decken das Lieferantenrisiko für den Modell-Herausgeber ab, nicht nur den Software-Anbieter. Ergänzen Sie danach die technologischen Kontrollen (A.8) — sie decken Verschlüsselung, Logging und Endpunkt-Härtung direkt ab. Auch relevant für Mittelstandsbetriebe nach BSI-Grundschutz-Logik, auch wenn ISO 27001 formal ein eigenständiger Standard ist.

Ein Auditor erwartet nachvollziehbar zu sehen, wer mit welcher Anmeldeinformation wann auf das Modell zugegriffen hat — eine Anforderung, die keine der gängigen selbst gehosteten Engines ohne vorgeschaltetes Gateway erfüllt. Ollama bindet standardmäßig an `127.0.0.1:11434` und kennt keine Benutzerkonten; vLLM und Hugging Face TGI stellen eine OpenAI-kompatible HTTP-API ohne integrierte Authentifizierung bereit.

Setzen Sie ein API-Gateway (Kong, Envoy oder die API-Management-Schicht eines Cloud-Anbieters) vor die Inference-Engine, um Anrufer-spezifische API-Keys oder OAuth2 zu ergänzen, und loggen Sie jede Anfrage mit Identität, Zeitstempel, Modellversion und Token-Zahlen in ein SIEM-fähiges System. Vermeiden Sie es, vollständige Prompt-/Response-Inhalte im selben Zugriffslog zu speichern — dafür gilt der separat geregelte Prompt-Log-Speicher unter Aufbewahrung.

Modellgewichte, Prompt-Logs und Response-Logs brauchen dieselbe Verschlüsselung ruhend und in Übertragung, die ein Auditor bereits für jeden anderen produktiven Datenspeicher erwartet. Die Gewichte selbst sind meist nicht geheim, aber die Festplatte des Inference-Servers enthält meist auch zwischengespeicherte Prompts, fein abgestimmte Adapter und Logs, die es sind.

Nutzen Sie Festplattenverschlüsselung (LUKS unter Linux, BitLocker unter Windows, FileVault unter macOS) auf dem Inference-Host als Basis. Ergänzen Sie TLS-Terminierung am Gateway für jeden eingehenden API-Aufruf — geben Sie den rohen Inference-Port niemals unverschlüsselt über HTTP frei, auch nicht innerhalb eines VPC. Nutzen Sie einen verwalteten KMS (AWS KMS, Azure Key Vault, HashiCorp Vault) für die Schlüssel des Prompt-Log-Speichers statt eines statischen Schlüssels in einer Konfigurationsdatei.

Jeder Modellversionswechsel, jede Quantisierungsänderung oder System-Prompt-Anpassung ist eine Produktivänderung und braucht dieselbe Freigabespur wie ein Code-Deployment. Auditoren suchen gezielt nach Nachweisen, dass Änderungen vor dem Go-Live geprüft und genehmigt wurden — nicht nur, dass ein Changelog im Nachhinein existiert.

Nutzen Sie ein versionsfixiertes Deployment (exakte Modell-Checksumme statt eines veränderlichen "latest"-Zeigers), damit ein Rollback möglich und nachvollziehbar ist. Nutzen Sie einen dokumentierten Freigabeschritt — auch ein schlanker, etwa eine Pull-Request-Review — vor jedem produktiven Modellwechsel, und protokollieren Sie Genehmiger, Datum und Änderungsgrund.

"Open-Weight" bedeutet nicht "kein Lieferant" — der Modell-Herausgeber ist eine Supply-Chain-Partei wie jeder SaaS-Anbieter, und ein Auditor erwartet dafür eine dokumentierte Risikobewertung. Dies ist eine der am häufigsten übersehenen Kontrollen: Teams behandeln eine heruntergeladene GGUF- oder Safetensors-Datei als intern, nicht als Drittanbieter-Artefakt, obwohl sie von außerhalb der Organisation stammt.

Nutzen Sie zunächst die Identität und Erfolgsbilanz des Herausgebers als ersten Check — ein Modell von Meta, Mistral AI, Alibaba/Qwen oder einer vergleichbar identifizierbaren Organisation hat ein anderes Risikoprofil als ein anonymer Upload. Verifizieren Sie die Datei-Checksumme gegen den vom Herausgeber veröffentlichten Hash vor dem Deployment. Prüfen Sie die Lizenzbedingungen auf Einschränkungen der kommerziellen Nutzung. Verfolgen Sie bekannte CVEs nicht im Modell selbst, sondern im Serving-Stack (llama.cpp, vLLM, TGI), der es lädt.

Ein Model-Serving-System hat Incident-Kategorien, die ein Standard-Web-App-Runbook nicht abdeckt — Modell-Exfiltration, Prompt-Injection, die über die Modellausgabe selbst Daten leakt, sowie eine Kompromittierung des Inference-Endpunkts — jede braucht einen benannten Reaktionspfad. Ein Auditor prüft, ob der Plan existiert und getestet wurde, nicht ob bereits ein Vorfall eingetreten ist.

Nutzen Sie Ihren bestehenden Incident-Response-Plan als Basis und ergänzen Sie modellspezifische Auslöser: unerwartete Änderungen an Modellgewichtsdateien, ungewöhnliche Anfragespitzen von einer einzelnen Anmeldeinformation oder Output-Logs mit einem Prompt-Injection-Muster.

Prompt-Logs sind die risikoreichsten Daten Ihres LLM-Stacks, weil sie oft dieselben sensiblen Inhalte enthalten, die ein Nutzer in jedes andere Geschäftssystem eingeben würde. Eine schriftliche Aufbewahrungsrichtlinie — wie lange Logs aufbewahrt, wer darauf zugreifen darf und wie sie gelöscht werden — ist eine Kontrolle, die ein Auditor gezielt sehen möchte, nicht nur aus Ihrer allgemeinen Datenschutzrichtlinie ableiten soll.

Nutzen Sie ein Aufbewahrungsfenster, das Ihrem tatsächlichen Audit- oder Debugging-Bedarf entspricht, nicht "standardmäßig alles für immer aufbewahren". Nutzen Sie Minimierung auf Feldebene, wo möglich — protokollieren Sie für Routineverkehr Metadaten (Anrufer, Zeitstempel, Token-Zahl, Modellversion) ohne vollständigen Prompt-Text, und reservieren Sie vollständiges Content-Logging für ein kürzeres, strenger zugriffskontrolliertes Fenster für Debugging oder Missbrauchsuntersuchung.

Der Inference-Server sollte in einer eigenen Netzwerkzone stehen, erreichbar nur über das authentifizierte Gateway — nicht flach im selben Subnetz wie allgemeine Anwendungsserver. Das begrenzt den Schadensradius, falls ein anderer Dienst im Netzwerk kompromittiert wird, und liefert dem Auditor ein sauberes Netzwerkdiagramm zur Prüfung.

Nutzen Sie ein dediziertes VLAN oder Subnetz für den Inference-Host, mit Firewall-Regeln, die eingehenden Traffic nur vom API-Gateway zulassen und ausgehenden Traffic auf das tatsächlich Benötigte beschränken (Modell-Registry-Abrufe, sofern vorhanden — viele Air-Gapped-Deployments blockieren ausgehenden Traffic nach dem Modell-Download vollständig).

Keine der gängigen Inference-Engines liefert einen fertigen Audit-Trail — der Unterschied liegt darin, wie viel Sie selbst bauen müssen gegenüber dem, was eine Plattform bereits bietet. Dies ist ein Bereitschaftsvergleich, keine Compliance-Aussage über eines dieser Tools.

Nutzen Sie Ollama oder vLLM, wenn Sie bereit sind, Gateway, Logging und Zugriffskontroll-Schicht selbst zu bauen. Nutzen Sie eine Enterprise-Inference-Plattform, wenn Sie lieber für integriertes RBAC und Audit-Logging bezahlen und den Instrumentierungsaufwand reduzieren möchten — die umgebende ISMS-Dokumentation brauchen Sie in beiden Fällen.

Compliance-Automatisierungsplattformen — Vanta, Drata und Secureframe sind die drei am häufigsten genutzten — rufen Nachweise automatisch aus Cloud-Infrastruktur, HR-Systemen und Identitätsanbietern ab, aber ein selbst gehosteter On-Prem-Inference-Server liegt meist außerhalb ihrer Standard-Integrationsliste. Diese Plattformen können die Nachweiserfassung für die Teile Ihrer Infrastruktur automatisieren, die sie integrieren (Cloud-Konten, Identitätsanbieter, Ticketsystem), während der Inference-Host selbst meist einen manuellen Nachweis-Upload oder eine individuelle API-Integration braucht.

Nutzen Sie eine Compliance-Automatisierungsplattform, wenn Sie ein breiteres SOC-2- oder ISO-27001-Programm im gesamten Unternehmen betreiben und kontinuierliches Monitoring für alles außer der selbst gehosteten LLM-Schicht wollen. Verzichten Sie darauf, wenn das LLM-Deployment Ihr einziges Prüfsystem ist — ein kleinerer, manuell gepflegter Nachweisordner kann für einen engen Geltungsbereich günstiger sein.

Die meisten Audit-Feststellungen bei selbst gehosteten LLMs entstehen dadurch, dass der Inference-Server außerhalb der normalen IT-Kontrollumgebung behandelt wird — nicht durch eine grundsätzlich fehlende Kontrolle. Das sind die fünf häufigsten Lücken.

Arbeiten Sie diese Checkliste durch, bevor die Vor-Ort-Prüfung Ihres Auditors beginnt — jeder Punkt bildet eine der oben behandelten Kontrollkategorien ab.