SOC 2 und ISO/IEC 27001 erklärt für Startups und kleine SoftwareunternehmenEin starkes Fundament. Nicht das ganze Bild.
SOC 2 und ISO/IEC 27001 sind wertvoll, und Ihre Kunden fragen womöglich danach. Sie beantworten eine wichtige Frage zu Ihrer Sicherheit. Ein Penetrationstest beantwortet eine andere. So sehen wir das Zusammenspiel.
Wir verkaufen Readiness-Unterstützung und Penetrationstests. Unser Interesse an diesem Thema
Sind unsere Sicherheitskontrollen und Prozesse festgelegt und funktionieren sie wie beschrieben?
Was können erfahrene Tester in unserem Produkt ausnutzen, in einem vereinbarten Umfang und Zeitraum?
Sie betrachten verschiedene Dinge. Keines ersetzt das andere.
~/what-they-give-you
Zuerst: was diese Frameworks gut leisten.
SOC 2 ist ein Prüfbericht (Assurance Report) eines zugelassenen US-Wirtschaftsprüfers (CPA) nach AICPA-Standards, kein Zertifikat. Eine Zertifizierung nach ISO/IEC 27001 bezieht sich auf ein Managementsystem. Beide sind breit anerkannt, und das aus gutem Grund.
Struktur
Sicherheit bekommt Verantwortliche, dokumentierte Risikoentscheidungen, Korrekturmaßnahmen und regelmäßige Aufmerksamkeit der Geschäftsführung.
Prüfung von außen
Ein qualifizierter Dritter prüft Ihre Kontrollen oder Ihr Managementsystem, statt dass Sie sich selbst bewerten.
Nachweise, die Käufer lesen können
Ein Bericht oder Zertifikat gibt Kunden etwas Konkretes zum Prüfen, mehr als eine Antwort im Fragebogen.
Eine gemeinsame Sprache
Kunden, Auditoren und Partner kennen diese Frameworks. Das erleichtert Gespräche über Sicherheit.
“Certification alone does not secure systems, prevent incidents, or eliminate human error. What it does provide is a framework that makes information security manageable […]”~/scope
Ein Bericht spricht für seinen Scope.
Bei SOC 2 legt das Management den Scope fest, und der Auditor prüft, ob er angemessen und zutreffend dargestellt ist. Ein ISO/IEC-27001-Scope kann ein ganzes Unternehmen oder einen abgegrenzten Teil davon umfassen.
Ein fokussierter Scope ist normal und oft sinnvoll. Er bedeutet nur, dass sich der Bericht nicht auf Systeme außerhalb davon bezieht. Deshalb lohnt sich ein Blick auf die Grenze.
3 von 9 Systemen in diesem Beispiel-Scope. Umfasst das Produkt selbst. Üblich und legitim für einen fokussierten ersten Bericht.
- Cloud-Konto APrüfungen bestanden
- Code-RepositoryPrüfungen bestanden
- Identity ProviderPrüfungen bestanden
- Firmen-LaptopsPrüfungen bestanden
- Cloud-Konto BNicht angebunden: keine Daten
- Neuer TestserverNicht angebunden: keine Daten
Ein erfundenes Beispiel, nicht auf ein Produkt bezogen.
~/connected-tools
Ein Dashboard berichtet über das, was angebunden ist.
Compliance-Plattformen sparen viel Zeit, weil sie Nachweise automatisch sammeln. Sie berichten über die Systeme und Konten, die an sie angebunden sind. Deshalb kommt es auf die Liste der angebundenen Systeme an.
- Ein neues System oder Konto ist vielleicht noch nicht angebunden.
- Eine Verbindung kann aufhören zu synchronisieren. Es lohnt sich, das regelmäßig zu prüfen.
- Manche Systeme werden aus guten Gründen ausgenommen, etwa eine Sandbox. Einige Plattformen dokumentieren, dass Auditoren Scope-Ausschlüsse sehen können. Das unterscheidet sich je nach Plattform und Aktion, also prüfen Sie Ihre.
Eine einfache Gewohnheit hilft: Vergleichen Sie die Liste der angebundenen Systeme mit dem, was Sie tatsächlich betreiben.
~/sampling
Audits prüfen Stichproben.
Auditoren prüfen üblicherweise eine Stichprobe statt jedes einzelnen Elements und erweitern sie, wenn sie Abweichungen finden. Das ist etablierte Prüfungspraxis, um zu beurteilen, ob ein Prozess funktioniert.
Eine Stichprobe soll Vertrauen in einen Prozess schaffen. Sie ist nicht darauf ausgelegt, jedes Konto, jedes Gerät oder jede Codezeile zu untersuchen.
~/timing
Prüfungen finden in Abständen statt. Ihr Produkt entwickelt sich weiter.
Ein SOC-2-Type-2-Bericht deckt einen genannten vergangenen Zeitraum ab. ISO/IEC-27001-Zertifikate laufen oft drei Jahre, mit Überwachungsaudits dazwischen, wie etwa im Schema ISO 27001 auf Basis von IT-Grundschutz des BSI. Ein Softwareteam liefert in der Zeit vielleicht jede Woche.
- Neues Feature live
- Neue Integration ergänzt
- Abhängigkeit aktualisiert
Diese Änderungen werden womöglich von einer späteren Prüfung erfasst. Bis dahin sprechen Ihre eigenen Prozesse und Tests für sie.
~/two-lenses
Kontrollen und Exploits sind verschiedene Fragen.
Eine Kontrollprüfung fragt, ob Schutzmaßnahmen vorhanden sind und wirken. Sie ist nicht dafür gedacht, eine Zahl in einer Webadresse zu ändern und zu schauen, wessen Daten zurückkommen. Diese Art von Prüfung gehört zu einem Penetrationstest.
Kontrollprüfung
- Mehrfaktor-Login vorgeschrieben
- Daten im Ruhezustand verschlüsselt
- Logging aktiviert
- Zugriffe vierteljährlich geprüft
All das kann vorhanden sein, und das ist gut.
$ curl -s -H "Authorization: Bearer $A" \
app.example.com/invoices/1042 | jq .owner
"Kunde B"Das kann es trotzdem geben, weil es eine andere Frage ist. Ein erfundenes Beispiel.
~/together
Jedes erfüllt seine eigene Aufgabe.
Manche Kunden und Auditoren verlangen zusätzlich einen Penetrationstest. Klären Sie also, ob Ihre einen erwarten. Seine Ergebnisse können in Ihre Compliance-Arbeit einfließen. Ein Penetrationstest ist eine Momentaufnahme und kann nicht beweisen, dass keine weiteren Schwachstellen existieren.
| Thema | SOC 2 | ISO/IEC 27001 | Penetrationstest |
|---|---|---|---|
| Leitfrage | Erfüllen die beschriebenen Kontrollen die Kriterien? | Wird Sicherheit als funktionierendes Managementsystem betrieben? | Was können Tester im vereinbarten Umfang ausnutzen? |
| Durchgeführt von | Einem zugelassenen CPA, nach AICPA-Standards | Einer Zertifizierungsstelle | Sicherheitstestern |
| Sie erhalten | Einen Prüfbericht (Attestation Report) | Ein Zertifikat mit genanntem Scope | Schwachstellen mit Nachweis und Behebung |
| Betrachtet | Kontrollen, zu einem Stichtag oder über einen Zeitraum | Prozesse, Risiken und Kontrollen | Vereinbarte Systeme, im Testzeitraum |
~/how-to-read
Einen Bericht oder ein Zertifikat lesen und mit nützlichen Fragen herausgehen.
Gehen Sie jeden Punkt in Ihrem eigenen Bericht oder dem eines Lieferanten durch. Markieren Sie, was Sie beantworten können, und erhalten Sie eine versandfertige Fragenliste. Das hilft beim Lesen des Dokuments. Es bewertet nicht die Sicherheit von irgendwem.
SOC-2-Bericht
ISO/IEC-27001-Zertifikat
$ ./next-step
Bereiten Sie sich auf das Audit vor. Ergänzen Sie einen Penetrationstest, wo er hilft.
Wir helfen kleinen Teams bei der Vorbereitung auf SOC 2 und ISO/IEC 27001 und testen Produkte mit den Methoden echter Angreifer, in einem vereinbarten Umfang. Sie können beides auch einzeln beauftragen.
oder per E-Mail crew@rivedrive.com
Unser Interesse an diesem Thema. Diese Seite bewirbt unsere Leistungen und gibt allgemeine Informationen. Wir verkaufen Leistungen rund um diese Frameworks, nämlich Readiness-Unterstützung einschließlich der Einrichtung von Compliance-Plattformen sowie Penetrationstests. Wir führen keine Zertifizierungsaudits durch und stellen keine SOC-2-Berichte aus. Wir haben keine Partnerschaft mit einer Compliance-Plattform oder einem Auditor und erhalten von ihnen keine Provision. Nichts hier ist Prüfungs- oder Rechtsberatung, und die Praxis unterscheidet sich zwischen Auditoren und Tools. Wir stehen in keiner Verbindung zu AICPA, ISO oder IEC.
Quellen
- ISO/IEC JTC 1/SC 27 Journal 2026, Ausgabe 1 (Zitat auf S. 42; Managementsysteme auf S. 4), Englisch ↗
- Sensiba: wie der SOC-2-Scope festgelegt wird (Englisch) ↗
- Linford & Co.: Stichproben in SOC-Prüfungen (Englisch) ↗
- BSI: Ablauf einer ISO-27001-Zertifizierung auf der Basis von IT-Grundschutz, ein Schema (Gültigkeit und Überwachungsaudits) ↗
- DAkkS, 15. November 2024: keine Pflicht zur Nutzung der IAF-CertSearch-Datenbank (Englisch) ↗