CSPM und CNAPP vs Compliance-Readiness: ergänzend, nicht konkurrierend

Was CSPM und CNAPP tatsächlich liefern

CSPM-Produkte bewerten Cloud-Ressourcenkonfigurationen fortlaufend gegen Policy-Bibliotheken: öffentlicher Storage, offene Security Groups, fehlende Verschlüsselung, schlafende Admin-Rechte und Hunderte ähnlicher Checks. CNAPP erweitert die Fläche auf Workloads, Identitäten, Schwachstellen und teils Laufzeitverhalten - weiterhin vor allem in der Familie „finden und beheben“.

Die meisten Anbieter publizieren Mappings ihrer Check-Kataloge auf SOC-2-Trust-Kriterien, CIS-Benchmarks, ISO-27001-Anhang-Referenzen oder PCI-Kontrollen. Diese Mappings helfen bei der Priorisierung. Sie erzeugen nicht von selbst eine in Ihrem Kontext geschriebene Kontrollbeschreibung, eine Risikobeurteilung mit Ihren kritischen Systemen oder Nachweise, dass eine Kontrolle über ein Beobachtungsfenster hinweg operiert hat.

Was Compliance-Readiness-Arbeit wirklich ist

Readiness - ob für SOC 2 Type II, ISO 27001, Kunden-Due-Diligence oder Sektorregeln wie DORA - ist die Arbeit, festzulegen, welche Kontrollen für Ihre Organisation gelten, sie in der Umgebung umzusetzen, die Sie tatsächlich betreiben, und Nachweise zu sammeln, dass sie konsistent operiert haben.

• ✓Kontrolldesign: Policies und technische Guardrails, die zu Ihren Build- und Betriebsweisen passen - kein generischer Benchmark in Confluence.
• ✓Betriebsverfahren: Incident Response, Access Reviews, Change Management, Backup-Restore-Tests - mit benannten Verantwortlichen und Kadenz.
• ✓Nachweise: Logs, Tickets, Freigaben, Konfigurationsexporte und Testergebnisse dort, wo ein Auditor stichprobenartig prüfen kann.
• ✓Scope und Narrativ: was im Scope ist, was explizit ausgeschlossen ist, und wie Subprozessoren und Cloud-Regionen in die Geschichte passen.

Wo Tool-Ebene und Readiness-Ebene zusammentreffen

Die sinnvolle Architektur ist gestapelt, nicht entweder-oder. CSPM/CNAPP (oder native Provider-Security-Hubs) liefern kontinuierliches detektives Signal und speisen oft Ticketing. Das Readiness-Programm übersetzt dieses Signal in Kontrollziele, definiert „compliant genug“ für Ihre Risikobereitschaft und stellt sicher, dass dieselben Checks in Ihrer Kontrollmatrix referenziert sind, sodass ein Auditor eine Geschichte sieht.

Beispiel: Eine CSPM-Regel markiert S3-Buckets ohne Verschlüsselung. Readiness-Arbeit entscheidet, ob Default-Verschlüsselung ein präventives SCP ist, dokumentiert die Kontrolle, belegt Durchsetzung über das Beobachtungsfenster und erfasst Ausnahmen mit Freigabe. Das Tool fand Lücken beim Rollout; das Programm macht das Ergebnis verteidigbar.

Typische Fehlermuster, wenn Tools Readiness ersetzen sollen

Teams, die „grünes Dashboard“ mit „bereit für Type II“ gleichsetzen, entdecken oft in der ersten Audit-Woche Lücken: fehlende Access-Review-Nachweise, BCP-Tests, die nie liefen, Lieferanten-Due-Diligence-Ordner, die beim Hyperscaler-MSA enden, oder Produktionsdaten in Umgebungen, die das Scope-Dokument vergessen hat.

Ein weiteres Muster ist Kontroll-Sprawl: Jeder CSPM-Befund wird zur „Kontrolle“ ohne Owner, ohne Kadenz und ohne Bezug zum Geschäftsrisiko. Auditoren verlangen Stichproben; das Team exportiert fünfzig PDFs aus einem Scanner ohne Joiner-Mover-Leaver-Geschichte. Erkennungsvolumen ist keine Kontrollreife.

Was Stratoworks tut - und bewusst nicht tut

Stratoworks verkauft oder betreibt kein CNAPP-Produkt. Wir engineerieren Landing Zones, Guardrails, Logging, Identitätsmuster und die Nachweispfade, die Frameworks erwarten - in Terraform und in Ihren Runbooks. Wenn Sie bereits Prisma Cloud, Wiz, Defender for Cloud oder Security Hub nutzen, integrieren wir dieses Signal statt es zu ersetzen.

Boutique-Readiness bedeutet hier hands-on Kontrollimplementierung und Audit-Vorbereitung für cloud-zentrierten Scope: kein Folienpaket mit „CSPM aktivieren“, sondern das SCP-Set, das Log-Archiv, das Restore-Test-Log und die Register-Zeile für Ihre produktive AWS-Organisation.

Eine praktische Sequenz, wenn Sie beides starten

Wenn Sie CSPM einführen und parallel ein Framework anstreben, ordnen Sie die Arbeit so, dass jede Ebene die nächste speist:

• ✓Estate-Grenze stabilisieren: Accounts, SSO, zentrales Logging - sonst produzieren Scanner Rauschen, auf das Sie nicht reagieren können.
• ✓CSPM-Policies an die Kontrollthemen Ihres Frameworks ausrichten, aber eigene Kontrollaussagen in klarer Sprache schreiben.
• ✓Kritische Fehlkonfigurationen beheben, die das Tool zeigt, dann präventive Guardrails fixieren, sodass Regressionen fail-closed sind.
• ✓Betriebsverfahren (Reviews, Restores, Incident-Tabletops) im Kalender fahren und Artefakte in einem Evidence Store ablegen.
• ✓Tool-Reports als ergänzende Nachweise nutzen, nicht als primären Beleg operativer Wirksamkeit.

FAQ