Erfüllt ist nicht nachgewiesen
In Container-Umgebungen fehlt selten eine Kontrolle. Der Regelfall ist eine Kontrolle, die faktisch wirkt, sich aber nicht belegen lässt. Über das Prüfergebnis entscheidet genau dieser Unterschied.
„Unsere Backups laufen jede Nacht und melden Erfolg."
Beleg: Screenshot des Dashboards, Stand unbekannt
„Am 14.03. wiederhergestellt, 3 h 12 min, zwei Abweichungen protokolliert."
Beleg: Restore-Protokoll mit Datum, Umfang, Dauer, Verantwortlichem
Audits scheitern an Dokumentation, nicht an Technik
In den meisten Container-Umgebungen, die wir sehen, sind die Kontrollen aus §30 Abs. 2 BSIG technisch weitgehend erfüllt. Zugriffe laufen über ein zentrales Identitätssystem, Images kommen aus einer eigenen Registry, Backups laufen nachts durch.
Nur: Der Prüfer fragt nicht, ob es so ist. Er fragt, woran er es sehen kann.
Und dann beginnt die Fleißarbeit. Screenshots, Excel-Listen, Zuarbeit aus vier Teams, ein Stand, der schon beim Zusammentragen veraltet. Das bindet über Wochen genau die Leute, die eigentlich die Plattform betreiben sollen, und im nächsten Jahr fängt es von vorn an.
Was deklarative Infrastruktur daran ändert
Eine deklarativ betriebene Plattform dreht das Verhältnis um: Der Nachweis entsteht als Nebenprodukt des Betriebs, nicht als Projekt vor dem Audit.
Der Soll-Zustand ist Code
Was gelten soll, steht in Git, nicht in einer Richtlinie, die beschreibt, was gelten soll. Der Unterschied entscheidet, ob eine Kontrolle prüfbar ist.
Die Änderungshistorie entsteht von selbst
Jede Änderung läuft über einen Pull Request mit Vier-Augen-Prinzip. Damit existiert ein lückenloser Änderungsnachweis, ohne dass jemand ihn führt.
Die Abweichung wird gemessen
Drift zwischen Git-Soll und Cluster-Ist ist eine Kennzahl mit Zeitreihe, keine Behauptung im Jahresbericht. Wirksamkeit wird kontinuierlich belegt statt stichprobenhaft geprüft.
Die Frage, mit der jedes Erstgespräch beginnt
Wann haben Sie zuletzt eine Wiederherstellung tatsächlich durchgeführt?
Nicht: Wann lief das letzte Backup erfolgreich durch. Sondern: Wann haben Sie zuletzt aus diesem Backup wiederhergestellt, die Dauer gemessen, die Abweichungen festgehalten und das Protokoll unterschrieben?
Eine Backup-Erfolgsmeldung ist kein Nachweis für Wiederherstellbarkeit. Sie belegt, dass ein Schreibvorgang funktioniert hat, nicht, dass Ihr Betrieb wieder anläuft.
Weil das Kriterium binär und in wenigen Stunden prüfbar ist, machen wir es zum Abnahmekriterium unserer Arbeit. Erfüllen kann es kaum jemand.
Drei Schritte, einzeln beauftragbar
1. Plattform-Compliance-Assessment
2–3 Wochen · 8–12 PersonentageIst-Aufnahme über alle zehn Maßnahmenbereiche. Sie erhalten:
- ▸Kontrollmatrix: jede Anforderung aus §30 Abs. 2 gegen den tatsächlichen Zustand Ihrer Cluster
- ▸Nachweisverzeichnis: für jede erfüllte Kontrolle der konkrete Fundort des Belegs. Der Teil, den intern niemand schreibt.
- ▸Priorisierter Maßnahmenplan: geordnet nach Risiko und Aufwand statt nach Vollständigkeit
- ▸Management-Summary auf zwei Seiten: für Geschäftsleitung und Revision, ohne Kubernetes-Vokabular
2. Umsetzungsgewerk „Nachweisfähige Plattform"
3–6 Monate · Module à 15–25 PersonentageWir setzen den Maßnahmenplan um. Jedes Modul hat ein Abnahmekriterium, das man bestehen oder nicht bestehen kann. Keine Statusberichte.
3. Betrieb und Nachweisführung
12 Monate · monatlichKern der Leistung ist der Quartalsbericht Nachweisfähigkeit: Konformitätsquote je Kontrolle mit Verlauf, Drift und mittlere Zeit bis zur Korrektur, Alter offener Findings, Anzahl manueller Eingriffe am Cluster.
Sie kaufen hier nicht den Betrieb. Bezahlt wird der Bericht, den Sie sonst jedes Quartal selbst zusammentragen müssten, und der laufende Betrieb ist die Voraussetzung dafür.
Die fünf Bereiche mit dem größten technischen Anteil
§30 Abs. 2 BSIG nennt zehn Maßnahmenbereiche. Fünf davon entscheiden sich auf der Plattformebene. Dort arbeiten wir, und dort entsteht der Nachweis, den ein Prüfer akzeptiert.
Bereich 3 · Betrieb und Wiederherstellung
Was wir umsetzen: Backups auf getrenntes Ziel mit unveränderlicher Aufbewahrung, Cluster-Wiederaufbau vollständig aus Git, RTO und RPO am Workload statt in Excel
Was Sie danach vorlegen können: Restore-Protokoll mit Datum, Umfang, gemessener Dauer und Abweichungen
Bereich 4 · Lieferkette
Was wir umsetzen: Eigene Registry, Allowlist per Admission Policy, Image-Signaturen mit Verifikation beim Start, SBOM je Artefakt
Was Sie danach vorlegen können: Policy-Report mit Anteil verifizierter Images, SBOM-Archiv, Abhängigkeitsinventar
Bereich 5 · Schwachstellenbehandlung
Was wir umsetzen: Scanning in der Pipeline und fortlaufend in der Registry, Admission-Regel je Schweregrad, befristetes Ausnahmeverfahren
Was Sie danach vorlegen können: Schwachstellen-Dashboard mit Alterung offener Findings, Zeitreihe der Patch-Dauer
Bereich 8 · Kryptographie
Was wir umsetzen: mTLS clusterintern, automatisierte Zertifikatsverwaltung mit Ablaufüberwachung, Secrets nie im Klartext in Git, protokollierte Rotation
Was Sie danach vorlegen können: Zertifikatsinventar mit Laufzeiten, Rotationsprotokolle
Bereich 9 · Zugriffskontrolle
Was wir umsetzen: Zugang ausschließlich über OIDC, RBAC an Gruppen statt Personen und vollständig in Git, Break-Glass mit Alarmierung, wirksames Offboarding
Was Sie danach vorlegen können: RBAC-Stand als versionierte Datei mit Historie, Nachweis der Offboarding-Wirksamkeit
Was wir ausdrücklich nicht machen
Diese Liste steht hier, weil sie in jedem Werkvertrag steht. Wir schneiden den Umfang lieber vorher als im Streitfall.
- ✕Aufbau oder Betrieb eines Informationssicherheits-Managementsystems
- ✕Begleitung zur ISO-27001-Zertifizierung
- ✕Risikoregister, Bewertungsmethodik, Informationssicherheitsleitlinie
- ✕Rechtsberatung, Betroffenheitsprüfung, Auslegungsfragen
- ✕Meldeprozess gegenüber dem BSI, Krisenstab, externe Kommunikation
- ✕Awareness- und Schulungsprogramme einschließlich Geschäftsleitungsschulung
- ✕Lieferantenbewertung, Vertragsklauseln, Prüfung von Subdienstleistern
- ✕Sprach-, Video- und Notfallkommunikation der Organisation
- ✕Personalprozesse und Zuverlässigkeitsüberprüfungen
Wenn Sie dafür jemanden brauchen: Wir arbeiten neben ISMS-Beratungen und Prüfern und übernehmen den technischen Teil ihres Projekts. Sagen Sie uns, wer bei Ihnen dafür zuständig ist. Die Schnittstelle klären wir vor Projektbeginn, damit im Werkvertrag steht, wo Ihr Umfang endet und unserer beginnt.
Passt das zu Ihnen?
- ✓Sie betreiben Container- oder Cloud-Workloads produktiv, nicht erst planend
- ✓Ihr Unternehmen hat 200 bis 2.000 Mitarbeitende und keine eigene Compliance-Abteilung für die Plattformebene
- ✓Sie sind in Energieversorgung, Software und SaaS, Health-IT oder Logistik tätig
- ✓Ihr Informationssicherheitsbeauftragter hat den Druck und sucht jemanden für die technische Seite
- ✕Sie müssen erst klären, ob §30 BSIG für Sie gilt. Das ist eine Rechtsfrage, keine technische.
- ✕Sie wollen ein ISMS aufbauen. Dann brauchen Sie zuerst eine ISMS-Beratung, und danach eventuell uns.
- ✕Sie sind Cloud-Anbieter, Rechenzentrumsdienstleister oder Managed-Service-Provider. Für diese Kategorien gilt nach §30 Abs. 4 BSIG vorrangig die EU-Durchführungsverordnung 2024/2690 mit einem eigenen Katalog.
- ✕Sie betreiben eine kritische Anlage. Dann kommen zusätzliche Pflichten hinzu, das ist ein anderes Projekt.
Wer das macht
Zwei Gesellschafter, rund zwanzig produktive Cluster. Kubernetes und GitOps kommen bei uns aus dem täglichen Betrieb, einschließlich Rufbereitschaft. Wer das Angebot schreibt, macht auch die Arbeit. Nach der Beauftragung wechselt niemand auf ein Juniorteam.
Unsere Debugging- und Pattern-Artikel stehen offen im Blog. Lesen Sie zwei davon, bevor Sie uns anfragen. Das ist der ehrlichste Kompetenznachweis, den wir anbieten können.
Für ISMS-Beratungen, Prüfer und Systemhäuser
Wenn Sie das Managementsystem verantworten und im Projekt an die Plattformebene stoßen: Wir übernehmen den technischen Teil und fassen Ihren nicht an. Die Liste oben ist unsere Geschäftsgrundlage, nicht Höflichkeit.
Wie wir arbeiten: gemeinsamer Auftritt beim Kunden, namentliche Nennung beider Seiten, klar geschnittener Umfang im Werkvertrag. Reines Weißlabel machen wir nicht.
Häufige Fragen
Was verlangt §30 BSIG technisch von einer Kubernetes-Umgebung? +
§30 Abs. 2 BSIG nennt zehn Maßnahmenbereiche, von Risikoanalyse über Backup und Lieferkette bis zu Zugriffskontrolle und Multi-Faktor-Authentifizierung. Der Gesetzestext ist technikneutral. In einer Container-Umgebung entscheidet deshalb nicht die Liste, sondern die Frage, welches Artefakt eine Kontrolle belegt: ein Policy-Report, ein Restore-Protokoll, eine RBAC-Historie.
Reicht unser ISO-27001-Zertifikat dafür aus? +
Ein bestehendes Managementsystem deckt nach verbreiteter Einschätzung große Teile der organisatorischen Anforderungen ab. Es sagt aber wenig darüber, ob die Kontrollen in Ihren Clustern technisch wirksam sind und ob Sie das je Kontrolle belegen können. Genau diese Lücke schließen wir. Ob das Zertifikat in Ihrem Fall ausreicht, beurteilt Ihr Informationssicherheitsbeauftragter oder Ihre Rechtsberatung.
Was ist der Unterschied zwischen erfüllt und nachgewiesen? +
Erfüllt heißt: Die Kontrolle wirkt. Nachgewiesen heißt: Sie können einem Prüfer zeigen, woran er das erkennt, mit Stand, Erzeugungszeitpunkt und Historie. In Container-Umgebungen ist fast immer der zweite Teil das Problem. Ein Screenshot ist eine Momentaufnahme, ein Policy-Report mit Zeitreihe ist ein Nachweis.
Was ist ein protokollierter Restore-Test? +
Eine tatsächlich durchgeführte Wiederherstellung aus dem Backup, mit gemessener Dauer, festgehaltenen Abweichungen und benanntem Verantwortlichen. Backup-Erfolgsmeldungen belegen nur, dass ein Schreibvorgang funktioniert hat. Prüfer fragen danach, weil das Kriterium binär ist: Entweder es gibt ein Protokoll mit Datum, oder es gibt keines.
Gilt das auch für Cloud-Anbieter und Managed-Service-Provider? +
Für bestimmte digitale Anbieter, darunter Cloud-Computing-Dienste, Rechenzentrumsdienste und Managed-Service-Provider, gilt nach §30 Abs. 4 BSIG vorrangig die EU-Durchführungsverordnung 2024/2690 mit einem eigenen, detaillierteren Katalog. Wenn Sie in diese Kategorien fallen, sagen wir Ihnen das im Vorgespräch, bevor wir ein Angebot schreiben.
Wie lange dauert ein Assessment und was brauchen Sie von uns? +
Zwei bis drei Wochen ab Zugang zu Clustern und Repositories, Aufwand acht bis zwölf Personentage. Von Ihrer Seite braucht es einen Ansprechpartner aus dem Plattformteam, zwei Termine und Lesezugriff. Ergebnis sind Kontrollmatrix, Nachweisverzeichnis und ein priorisierter Maßnahmenplan.
Ersetzt ein technischer Umsetzungspartner den Informationssicherheitsbeauftragten? +
Nein, und das ist keine Höflichkeitsfloskel. Risikoregister, Bewertungsmethodik, Leitlinie, Meldeprozess und Managementbewertung bleiben bei ihm. Wir liefern die technische Umsetzung auf der Plattformebene und die Artefakte, mit denen er seine Nachweisführung bestückt.