NIS2-Audit bestehen: Was Pruefer wirklich sehen wollen

TL;DR

• Auditoren pruefen nicht nur Technik, sondern vor allem Prozesse: Dokumentation, Verantwortlichkeiten, Nachweisfuehrung und kontinuierliche Verbesserung zaehlen mehr als die perfekte Konfiguration.
• Die drei haeufigsten Audit-Findings in Kubernetes-Umgebungen sind: fehlende Audit-Log-Retention, undokumentierte RBAC-Berechtigungen und fehlende Incident-Response-Tests.
• Vorbereitung braucht 8-12 Wochen bei einem Team, das die technischen Grundlagen bereits umgesetzt hat. Ohne Grundlagen rechnen Sie mit 6-9 Monaten.
• Policy-as-Code ist der staerkste Audit-Nachweis: Kyverno- oder OPA-Policies in Git sind besser als jede Excel-Checkliste, weil sie nachweisbar durchgesetzt werden.
• Der Audit selbst ist nicht das Problem -- die Vorbereitung entscheidet. Wer seine Hausaufgaben macht, besteht den Audit ohne Findings.

Wie ein NIS2-Audit ablaeuft

Ein NIS2-Audit ist kein Ueberraschungsbesuch. Der Ablauf folgt einem klaren Muster:

Der Pruefer kommt mit einer Erwartungshaltung: Er will sehen, dass Sie die NIS2-Anforderungen verstanden haben, systematisch umgesetzt haben und dauerhaft betreiben. Perfekte Technik bei fehlender Dokumentation ist genauso ein Finding wie gute Dokumentation bei schlechter Technik.

Die 10 Pruefbereiche im NIS2-Audit

NIS2 Art. 21 definiert zehn Massnahmenbereiche. Jeder davon wird im Audit geprueft. Hier ist, was Auditoren in Kubernetes-Umgebungen konkret sehen wollen:

1. Risikoanalyse und Sicherheitskonzept

Was der Pruefer fragt:

• Haben Sie eine dokumentierte Risikoanalyse fuer Ihre Kubernetes-Infrastruktur?
• Werden Risiken regelmaessig neu bewertet?
• Gibt es ein Sicherheitskonzept mit klaren Verantwortlichkeiten?

Was Sie zeigen muessen:

• Risikoregister mit Kubernetes-spezifischen Risiken (Container-Ausbruch, Supply-Chain-Angriff, Fehlkonfiguration)
• Dokumentierte Risikobewertung mit Eintrittswahrscheinlichkeit und Schadenshoehe
• Massnahmenplan mit Status und Verantwortlichen

Typisches Finding: "Risikoanalyse existiert, beruecksichtigt aber Container-spezifische Risiken nicht. Letztes Update vor 14 Monaten."

2. Incident Handling

Was der Pruefer fragt:

• Wie schnell erkennen Sie einen Sicherheitsvorfall?
• Koennen Sie die 24-Stunden-Meldepflicht einhalten?
• Wann haben Sie zuletzt einen Incident-Response-Test durchgefuehrt?

Was Sie zeigen muessen:

• Dokumentierter Incident-Response-Plan mit Eskalationsstufen
• Nachweis der Meldekette (Wer wird wann informiert?)
• Protokoll des letzten IR-Tests oder Table-Top-Exercises

3. Business Continuity

Was der Pruefer fragt: Wie lange dauert die Wiederherstellung? Wann wurde zuletzt ein Recovery getestet? Gibt es einen DR-Plan?

Was Sie zeigen muessen: RTO/RPO pro Service, Protokoll des letzten DR-Tests, Backup-Konfiguration mit Retention-Nachweis.

4. Supply-Chain-Security

Was der Pruefer fragt: Woher kommen Ihre Container-Images? Scannen Sie auf Schwachstellen? Koennen Sie die Herkunft nachweisen?

Was Sie zeigen muessen: SBOM (Software Bill of Materials) fuer produktive Images, Trivy-Scan-Reports, Image-Signing-Nachweise.

Technische Checkliste: Kubernetes NIS2-Audit

Cluster-Haertung

Die Basis jeder NIS2-Pruefung ist ein gehaerteter Cluster. Auditoren vergleichen Ihre Konfiguration gegen den CIS Kubernetes Benchmark. Fuehren Sie vor dem Audit einen kube-bench-Scan durch und dokumentieren Sie die Ergebnisse.

#!/bin/bash
# NIS2 Pre-Audit: Cluster-Haertung pruefen und dokumentieren

echo "=========================================="
echo "NIS2 Pre-Audit Report - $(date +%Y-%m-%d)"
echo "=========================================="

# 1. CIS Benchmark mit kube-bench
echo ""
echo "--- CIS Kubernetes Benchmark ---"
kubectl run kube-bench-audit --image=aquasecurity/kube-bench:latest \
  --restart=Never \
  --overrides='{
    "spec": {
      "hostPID": true,
      "containers": [{
        "name": "kube-bench",
        "image": "aquasecurity/kube-bench:latest",
        "command": ["kube-bench", "run", "--json"],
        "volumeMounts": [
          {"name": "var-lib-kubelet", "mountPath": "/var/lib/kubelet", "readOnly": true},
          {"name": "etc-kubernetes", "mountPath": "/etc/kubernetes", "readOnly": true}
        ]
      }],
      "volumes": [
        {"name": "var-lib-kubelet", "hostPath": {"path": "/var/lib/kubelet"}},
        {"name": "etc-kubernetes", "hostPath": {"path": "/etc/kubernetes"}}
      ]
    }
  }'

# 2. Pods mit Root-Rechten finden
echo ""
echo "--- Container mit Root-Rechten (NIS2-Risiko) ---"
kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] |
    select(.spec.containers[]?.securityContext?.runAsNonRoot != true) |
    "\(.metadata.namespace)/\(.metadata.name)"'

# 3. Namespaces ohne ResourceQuotas
echo ""
echo "--- Namespaces ohne ResourceQuotas ---"
for ns in $(kubectl get namespaces -o jsonpath='{.items[*].metadata.name}'); do
  quota_count=$(kubectl get resourcequotas -n "$ns" --no-headers 2>/dev/null | wc -l)
  if [ "$quota_count" -eq 0 ] && [ "$ns" != "kube-system" ] && [ "$ns" != "kube-public" ]; then
    echo "WARNUNG: $ns"
  fi
done

# 4. Secrets-Encryption pruefen
echo ""
echo "--- Secrets Encryption Status ---"
kubectl get secrets --all-namespaces --no-headers | wc -l
echo "Secrets gefunden. Pruefen Sie: Ist EncryptionConfiguration aktiv?"

Fuer eine vollstaendige Haertungs-Anleitung empfehlen wir unseren Security Hardening Guide.

Audit-Logging: Was aufgezeichnet werden muss

Auditoren pruefen, ob Ihre Audit-Logs vollstaendig, manipulationssicher und ausreichend lange gespeichert werden. NIS2 verlangt mindestens die Nachweisfuehrung ueber signifikante Ereignisse.

# Kubernetes Audit Policy fuer NIS2-Compliance
apiVersion: audit.k8s.io/v1
kind: Policy
metadata:
  name: nis2-audit-policy
rules:
  # Alle Authentifizierungsfehler vollstaendig loggen
  - level: RequestResponse
    users: ["system:anonymous"]
    verbs: ["*"]

  # Secret-Zugriffe protokollieren (ohne Inhalt)
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]

  # RBAC-Aenderungen vollstaendig loggen
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]

  # Pod-Erstellung und -Loeschung loggen
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods"]
    verbs: ["create", "delete", "patch"]

  # Namespace-Aenderungen loggen
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["namespaces"]
    verbs: ["create", "delete", "update"]

  # NetworkPolicy-Aenderungen loggen
  - level: RequestResponse
    resources:
      - group: "networking.k8s.io"
        resources: ["networkpolicies"]

  # Alles andere: nur Metadaten
  - level: Metadata
    omitStages:
      - RequestReceived

Wichtig fuer den Audit: Der Pruefer will nicht nur sehen, dass Sie Audit-Logs haben, sondern dass Sie sie auch auswerten. Richten Sie Alerts ein, die bei verdaechtigen Mustern ausloesen (z.B. mehrfache fehlgeschlagene Authentifizierungsversuche, ungewoehnliche Secret-Zugriffe).

Dokumentation: Das unterschaetzte Audit-Thema

Was Auditoren in Ihrer Dokumentation suchen

Technische Konfigurationen allein reichen nicht. Auditoren erwarten eine strukturierte Dokumentation, die folgende Bereiche abdeckt:

Policy-as-Code als Dokumentation

Der staerkste Nachweis, den Sie einem Auditor vorlegen koennen, ist Policy-as-Code. Kyverno-Policies in einem Git-Repository sind gleichzeitig technische Durchsetzung und Dokumentation.

# Kyverno Policy: NIS2-konforme Pod-Security
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: nis2-pod-security-baseline
  annotations:
    nis2-requirement: "Art. 21 Abs. 2 lit. a - Risikoanalyse"
    nis2-control: "Container muessen als Non-Root laufen"
    last-review: "2026-02-10"
    reviewer: "security-team"
    policies.kyverno.io/description: >
      Stellt sicher, dass alle Pods gemaess NIS2-Anforderungen
      als Non-Root laufen und keine Privilegien eskalieren koennen.
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: require-non-root
      match:
        any:
          - resources:
              kinds:
                - Pod
      exclude:
        any:
          - resources:
              namespaces:
                - kube-system
                - falco-system
      validate:
        message: >
          NIS2-Compliance: Pods muessen als Non-Root laufen.
          Setzen Sie securityContext.runAsNonRoot auf true.
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true
                  allowPrivilegeEscalation: false
    - name: require-resource-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      exclude:
        any:
          - resources:
              namespaces:
                - kube-system
      validate:
        message: >
          NIS2-Compliance: Alle Container muessen CPU- und
          Memory-Limits definiert haben.
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"

Der Vorteil: Die Git-History zeigt dem Auditor, wann welche Policy eingefuehrt wurde, wer sie reviewed hat und ob sie tatsaechlich enforced wird. Das ist ein staerkerer Nachweis als jedes PDF-Dokument.

Mehr zu RBAC und Zugriffskontrolle im RBAC Enterprise Guide.

Die 7 haeufigsten Audit-Findings in Kubernetes-Umgebungen

Vorbereitungs-Timeline: 12 Wochen zum bestandenen Audit

Voraussetzung: Technische Grundlagen sind implementiert

Wenn Sie bereits RBAC, Network Policies, Audit-Logging und Image Scanning im Einsatz haben, dauert die Audit-Vorbereitung 12 Wochen. Falls nicht, lesen Sie zuerst unseren Compliance-Guide ohne Security-Team.

Woche 1-2: Dokumentations-Inventur
  - Welche Dokumente existieren bereits?
  - Welche muessen erstellt oder aktualisiert werden?
  - Lueckenanalyse gegen die 10 NIS2-Massnahmenbereiche

Woche 3-4: Risikoanalyse und Sicherheitskonzept
  - Kubernetes-spezifische Risikoanalyse durchfuehren
  - Sicherheitskonzept schreiben oder aktualisieren
  - Verantwortlichkeiten dokumentieren

Woche 5-6: Technische Nachweise sammeln
  - kube-bench-Report generieren und Findings dokumentieren
  - RBAC-Matrix erstellen
  - NetworkPolicy-Uebersicht erzeugen
  - Trivy-Scan-Reports archivieren

Woche 7-8: Prozesse testen
  - Incident-Response-Test (Table-Top-Exercise)
  - Backup-Recovery-Test durchfuehren
  - Ergebnisse protokollieren

Woche 9-10: Internes Pre-Audit
  - Eigene Checkliste gegen NIS2 Art. 21 abarbeiten
  - Schwachstellen in Dokumentation identifizieren
  - Letzte Luecken schliessen

Woche 11-12: Feinschliff und Trockenuebuung
  - Alle Dokumente finalisieren
  - Interview-Vorbereitung (Wer antwortet auf welche Fragen?)
  - Technische Demo vorbereiten (Kyverno, Falco, Monitoring)

Am Audit-Tag: Demos und Interviews

Bereiten Sie vier Live-Demos vor: (1) Policy Enforcement -- deployen Sie einen nicht-konformen Pod und zeigen Sie, wie Kyverno ihn blockiert, (2) Audit-Log-Auswertung -- verfolgen Sie einen spezifischen Zugriff in den Logs nach, (3) Alert-Pipeline -- loesen Sie einen Test-Alert aus und zeigen Sie den Weg bis zur Benachrichtigung, (4) RBAC-Nachweis -- demonstrieren Sie, dass ein Entwickler-ServiceAccount keinen Zugriff auf fremde Namespaces hat.

Auditoren fuehren Interviews mit Geschaeftsfuehrung, IT-Leitung, DevOps und Datenschutz. Bereiten Sie jede Rolle vor: Die GF muss NIS2-Anforderungen und Budget kennen, die IT-Leitung die Sicherheitsarchitektur erklaeren, DevOps die technische Umsetzung demonstrieren koennen.

Wichtig: Auditoren sind keine Gegner. Wenn Sie einen Mangel offen ansprechen und einen Plan zur Behebung zeigen, wird das positiver bewertet als ein versteckter Mangel. Audit-Findings werden in Major (4-8 Wochen Frist), Significant (8-12 Wochen) und Observations (naechster Zyklus) eingeteilt.

Checkliste: NIS2-Audit-Readiness

Fuer den Aufbau eines vollstaendigen Monitoring-Stacks empfehlen wir unseren Observability Guide.

Fazit: Audits bestehen ist planbar

Ein NIS2-Audit ist kein Gluecksspiel. Wer die technischen Grundlagen implementiert hat, seine Prozesse dokumentiert und regelmaessig testet, wird bestehen. Die haeufigsten Gruende fuer gescheiterte Audits sind nicht technische Maengel, sondern fehlende Dokumentation und nicht getestete Prozesse.

Starten Sie mit der Lueckenanalyse. Arbeiten Sie die 12-Wochen-Timeline ab. Und bereiten Sie Ihr Team auf die Interviews vor. Dann ist der Audit-Tag kein Stresstest, sondern eine Bestaetigung Ihrer Arbeit.

Wenn Ihnen die interne Kapazitaet fuer die Vorbereitung fehlt, kann ein 24/7 Managed Service sowohl den laufenden Betrieb als auch die Audit-Vorbereitung abdecken.

Sie stehen vor Ihrem ersten NIS2-Audit und brauchen Unterstuetzung bei der Vorbereitung? Wir begleiten Mittelstaendler von der Gap-Analyse bis zum bestandenen Audit -- pragmatisch und ohne Berater-Overhead. Sprechen Sie uns an.