RD SecurityEN (English)Erstgespräch buchen (öffnet Google Kalender in einem neuen Tab)

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

zwei verschiedene Fragen
SOC 2 und ISO/IEC 27001

Sind unsere Sicherheitskontrollen und Prozesse festgelegt und funktionieren sie wie beschrieben?

Penetrationstest

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 […]”
Erin Casteel, „ISO/IEC 27001 as a market entry ticket and trust as an enabler to trade“, ISO/IEC JTC 1/SC 27 Journal 2026, Ausgabe 1, S. 42, über ISO/IEC 27001. Die Ansicht der Autorin. Sinngemäß: Eine Zertifizierung allein sichert keine Systeme, verhindert keine Vorfälle und beseitigt keine menschlichen Fehler. Sie liefert aber einen Rahmen, der Informationssicherheit beherrschbar macht.

~/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.

Web-AppAPIKundendatenAdmin-ToolSupport-ToolCloud-KontoFirmen-LaptopsTestserverInterne Apps

3 von 9 Systemen in diesem Beispiel-Scope. Umfasst das Produkt selbst. Üblich und legitim für einen fokussierten ersten Bericht.

Systeme, die Daten liefern4 von 6
  • 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.

Nur zur Veranschaulichung: 25 von 120 Elementen ausgewählt. Echte Stichprobengrößen hängen von Grundgesamtheit und Methode ab.

~/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.

Prüfungszeitraum
Bericht ausgestellt
  • 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.

Penetrationstest, eingeloggt als Kunde A
$ 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.

ThemaSOC 2ISO/IEC 27001Penetrationstest
LeitfrageErfüllen die beschriebenen Kontrollen die Kriterien?Wird Sicherheit als funktionierendes Managementsystem betrieben?Was können Tester im vereinbarten Umfang ausnutzen?
Durchgeführt vonEinem zugelassenen CPA, nach AICPA-StandardsEiner ZertifizierungsstelleSicherheitstestern
Sie erhaltenEinen Prüfbericht (Attestation Report)Ein Zertifikat mit genanntem ScopeSchwachstellen mit Nachweis und Behebung
BetrachtetKontrollen, zu einem Stichtag oder über einen ZeitraumProzesse, Risiken und KontrollenVereinbarte 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.

Was lesen Sie?
Wessen Dokument ist es?

SOC-2-Bericht

Typ und Zeitraum

Wo Sie nachsehen: Erste Seiten und Prüfungsurteil des Auditors

Type 1 betrachtet die Ausgestaltung der Kontrollen zu einem Stichtag. Type 2 prüft zusätzlich, ob die Kontrollen über einen Zeitraum funktioniert haben, üblicherweise 3 bis 12 Monate. Ein Bridge Letter ist eine eigene, ungeprüfte Erklärung des Unternehmens zur Zeit danach.

Mögliche Frage: Ist das ein Type-1- oder Type-2-Bericht, welchen Zeitraum deckt er ab, und gibt es einen neueren Bericht oder einen Bridge Letter?

Abgedeckte Kategorien

Wo Sie nachsehen: Prüfungsurteil und Systembeschreibung

Security ist immer enthalten. Availability, Confidentiality, Processing Integrity und Privacy sind optional.

Mögliche Frage: Welche Trust-Services-Kategorien sind abgedeckt, und gehört dazu, wofür wir uns auf Sie verlassen?

Systembeschreibung

Wo Sie nachsehen: Systembeschreibung, meist der längste Abschnitt

Vom Management verfasst. Prüfen Sie, ob sie das Produkt und die Systeme nennt, die Sie tatsächlich nutzen.

Mögliche Frage: Deckt der Bericht das Produkt und die Systeme ab, die unsere Daten verarbeiten? Liegt etwas, das wir nutzen, außerhalb des Scopes?

Prüfungsurteil

Wo Sie nachsehen: Bericht des Auditors

Ein uneingeschränktes Urteil (unqualified opinion) ist ein sauberes Urteil, aber keine Sicherheitsgarantie. Ein eingeschränktes, versagtes oder nicht abgegebenes Urteil verdient einen genaueren Blick.

Mögliche Frage: Welche Art von Prüfungsurteil hat der Auditor abgegeben? Falls es nicht uneingeschränkt war, was war betroffen und was hat sich seitdem geändert?

Abweichungen

Wo Sie nachsehen: Kontrolltests und Ergebnisse (nur Type 2)

Eine Abweichung (Exception) ist nicht automatisch schlecht, und eine klare Darstellung ist hilfreich. Lesen Sie, was gefunden wurde und wie das Management reagiert hat.

Mögliche Frage: Welche Abweichungen wurden festgestellt, und wie ist der aktuelle Stand bei jeder davon?

Subdienstleister

Wo Sie nachsehen: Systembeschreibung

Das sind Anbieter, auf die sich das Unternehmen stützt, etwa Cloud-Hoster. Bei der Carve-out-Methode hat der Auditor deren Kontrollen nicht geprüft, und der Bericht kann Kontrollen nennen, die er bei ihnen voraussetzt. Bei der Inclusive-Methode hat er sie geprüft.

Mögliche Frage: Welche Subdienstleister sind ausgeklammert (Carve-out), wie prüfen Sie diese, und verarbeitet einer davon unsere Daten?

Was Kunden tun müssen

Wo Sie nachsehen: Meist in der Systembeschreibung unter „Complementary User Entity Controls“

Das sind Kontrollen, die Kunden auf ihrer Seite umsetzen sollen, damit die Kontrollen im Bericht wirksam sind.

Mögliche Frage: Welche Complementary User Entity Controls gelten für uns, und sind einige für unser Setup besonders wichtig?

Wer ihn ausgestellt hat

Wo Sie nachsehen: Bericht und Unterschrift des Auditors

Notieren Sie die unterzeichnende Prüfungsgesellschaft und den genannten Prüfungsstandard. Angaben zu Zulassung und Peer Review stehen meist außerhalb des Berichts.

Mögliche Frage: Welche Gesellschaft hat den Bericht ausgestellt, und können Sie bei Bedarf deren Zulassung und Peer Review belegen?

Gesonderte Sicherheitstests

Wo Sie nachsehen: Oft außerhalb des SOC-2-Berichts

Ein SOC-2-Bericht kann einen Penetrationstest erwähnen, muss es aber nicht. Wenn er Ihnen wichtig ist, fragen Sie gesondert.

Mögliche Frage: Gibt es einen aktuellen Penetrationstest? Wenn ja, welchen Umfang und welches Datum hatte er, und können Sie eine Zusammenfassung teilen?

$ ./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