SOC 2 Trust-Service-Kriterien: Der vollständige Leitfaden

Die Trust-Service-Kriterien (TSC) bilden das Rückgrat jedes SOC 2 Berichts. Sie wurden vom AICPA (American Institute of Certified Public Accountants) entwickelt und gepflegt und definieren die genauen Standards, gegen die Ihr Prüfer Ihre Kontrollen bewertet. Es handelt sich nicht um optionale Richtlinien oder Best-Practice-Empfehlungen — sie sind das formelle Bewertungsframework, das bestimmt, ob Ihr SOC 2 Bericht sauber ausfällt oder voller Ausnahmen ist.

Für SaaS-Unternehmen, die SOC 2 Compliance anstreben, ist das Verständnis der TSC nicht nur akademisch. Die Kriterien, die Sie auswählen, bestimmen direkt den Umfang Ihres Audits, die Kontrollen, die Sie implementieren müssen, die Nachweise, die Sie sammeln müssen, und letztlich die Kosten und den Zeitplan des gesamten Engagements. Wählen Sie zu wenige und Ihr Bericht wird Enterprise-Käufer möglicherweise nicht zufriedenstellen. Wählen Sie zu viele und Sie verpflichten sich zu Kontrollen, die Ihre Organisation möglicherweise nicht aufrechterhalten kann.

Dieser Leitfaden schlüsselt alle fünf Kriterien im Detail auf, erklärt, wann jedes einzelne zutrifft, und bietet ein praktisches Framework zur Auswahl der richtigen Kombination für Ihr SaaS-Geschäft.

Was sind die Trust-Service-Kriterien?

Das TSC-Framework — früher als Trust Service Principles (TSP) bekannt, bevor das AICPA sie 2017 umbenannte — besteht aus fünf Kategorien, die die grundlegenden Eigenschaften eines gut verwalteten Informationssystems abdecken:

1. Sicherheit (Common Criteria)
2. Verfügbarkeit
3. Verarbeitungsintegrität
4. Vertraulichkeit
5. Datenschutz

Jedes Kriterium enthält spezifische Fokuspunkte, die auf einzelne Kontrollen innerhalb Ihrer Organisation abgebildet werden. Ihr Prüfer testet diese Kontrollen während des SOC 2 Audit-Prozesses, um festzustellen, ob sie angemessen gestaltet (Type I) oder über einen Zeitraum wirksam betrieben wurden (Type II).

Wichtige Unterscheidung: Sie müssen nicht alle fünf Kriterien in Ihren SOC 2 Bericht aufnehmen. Sicherheit ist Pflicht. Die verbleibenden vier werden basierend auf Ihrem Geschäftsmodell, den Anforderungen Ihrer Kunden und der Art der von Ihnen verarbeiteten Daten ausgewählt.

Sicherheit (Common Criteria — CC)

Sicherheit ist das einzige Pflichtkriterium in jeder SOC 2 Prüfung. Das AICPA bezeichnet es als „Common Criteria”, weil seine Kontrollen allen anderen Trust-Service-Kategorien zugrunde liegen. Selbst wenn Sie nur Sicherheit einbeziehen, erhalten Sie dennoch einen vollständigen SOC 2 Bericht.

Was es abdeckt

Das Sicherheitskriterium befasst sich damit, ob Ihr System gegen unbefugten Zugriff geschützt ist — sowohl physisch als auch logisch. Es umfasst neun Kontrollkategorien (CC1 bis CC9), die zusammen ein umfassendes Sicherheitsframework bilden:

• CC1: Kontrollumgebung — Governance, Organisationsstruktur, Verantwortlichkeit und Verpflichtung zu Integrität und ethischen Werten
• CC2: Kommunikation und Information — Wie Sicherheitsrichtlinien und Verantwortlichkeiten intern und extern kommuniziert werden
• CC3: Risikobewertung — Identifizierung und Analyse von Risiken, die das Erreichen von Zielen verhindern könnten (siehe unseren SOC 2 Leitfaden zur Risikobewertung)
• CC4: Überwachungsaktivitäten — Laufende Bewertung der Kontrollen, um sicherzustellen, dass sie weiterhin wie vorgesehen funktionieren
• CC5: Kontrollaktivitäten — Die spezifischen Richtlinien und Verfahren, die identifizierte Risiken mindern
• CC6: Logische und physische Zugriffskontrollen — Authentifizierung, Autorisierung, Netzwerksicherheit und physischer Gebäudeschutz
• CC7: Systembetrieb — Überwachung auf Anomalien, Incident Detection und Reaktionsverfahren
• CC8: Change Management — Wie Änderungen an Infrastruktur, Software und Konfigurationen autorisiert, getestet und bereitgestellt werden
• CC9: Risikominderung — Prozesse zur Steuerung von Risiken aus Geschäftsbeziehungen und Lieferantenabhängigkeiten

Für eine detaillierte Übersicht über jede Kontrollkategorie lesen Sie unseren SOC 2 Common Criteria Detailleitfaden.

SaaS-Beispiele in der Praxis

In der Praxis: Ein B2B-SaaS-Unternehmen, das Sicherheitskontrollen implementiert, würde typischerweise Folgendes nachweisen:

• Multi-Faktor-Authentifizierung (MFA) für alle Mitarbeiter, die auf Produktionssysteme und Kundendaten zugreifen
• Verschlüsselung bei der Übertragung (TLS 1.2+) für alle API-Endpunkte und kundenorientierten Anwendungsverkehr
• Netzwerksegmentierung zur Trennung von Produktions-, Staging- und Unternehmensumgebungen
• Schwachstellenmanagement mit regelmäßigen Scans und einem definierten SLA für das Patching kritischer Schwachstellen
• Change Management, das Peer-Reviews von Pull Requests, automatisierte CI/CD-Tests und genehmigte Deployment-Fenster erfordert
• Zentralisiertes Logging mit Alerting bei verdächtigen Authentifizierungsversuchen, Privilege Escalations und Konfigurationsänderungen

Warum es für SaaS-Teams wichtig ist

Jeder Enterprise-Käufer erwartet, dass Sicherheit enthalten ist. Es ist die Grundlinie. Wenn Ihr SOC 2 Bericht nur Sicherheit abdeckt, ist das für viele Beschaffungsteams akzeptabel. Aber die Kontrollen hier sind nicht trivial — CC6 (Zugriffskontrollen) und CC7 (Systembetrieb) allein können während eines Type II Audits Dutzende von Nachweisanforderungen generieren.

Verfügbarkeit

Das Verfügbarkeitskriterium befasst sich damit, ob Ihr System wie zugesagt oder vereinbart betrieben wird und zugänglich ist. Es geht nicht darum, 100% Uptime zu erreichen — es geht darum, die Kontrollen zu haben, die das Servicelevel einhalten, das Sie Ihren Kunden versprochen haben.

Was es abdeckt

Verfügbarkeitskontrollen konzentrieren sich auf:

• Leistungsüberwachung — Verfolgung von Systemmetriken anhand definierter Schwellenwerte
• Disaster Recovery (DR) — Dokumentierte Verfahren zur Wiederherstellung des Services nach einem größeren Vorfall
• Business-Continuity-Planung (BCP) — Sicherstellung, dass kritische Funktionen bei Störungen fortgesetzt werden
• Kapazitätsplanung — Proaktives Management der Infrastruktur zur Vermeidung von Ressourcenerschöpfung
• Backup-Verfahren — Regelmäßige, getestete Backups mit definierten Recovery Point Objectives (RPO) und Recovery Time Objectives (RTO)
• Incident Response — Verfahren zur Erkennung, Reaktion und Wiederherstellung bei Verfügbarkeitsereignissen (siehe unseren SOC 2 Incident-Response-Leitfaden)

Wann Verfügbarkeit einbezogen werden sollte

Beziehen Sie Verfügbarkeit ein, wenn:

• Sie SLAs (Service Level Agreements) für Kunden anbieten, ob vertraglich oder auf Ihrer Statusseite veröffentlicht
• Ihre Kunden auf Ihren Service für ihren eigenen Betrieb angewiesen sind (z. B. Sie verarbeiten deren Transaktionen, hosten deren Daten oder betreiben deren Workflows)
• Ausfallzeiten Ihres Services direkt finanzielle Verluste oder Betriebsunterbrechungen für Kunden verursachen
• Sie in einer regulierten Branche tätig sind, in der Verfügbarkeitsanforderungen explizit sind

SaaS-Beispiel: Ein Projektmanagement-SaaS mit einem 99,9% Uptime-SLA benötigt Verfügbarkeitskontrollen, um nachzuweisen, dass das Monitoring, die Redundanz und die Wiederherstellungsmechanismen vorhanden sind, die dieses Versprechen untermauern. Ein Prüfer wird testen, ob DR-Pläne ausgeführt wurden, ob Backups getestet werden und ob die Kapazität überwacht wird — nicht nur, dass ein Richtliniendokument existiert.

Kontrollen im Detail

• Redundanz und Failover — Multi-AZ- oder Multi-Region-Deployments, Datenbankreplikation, Load Balancing mit Health Checks
• Monitoring und Alerting — Infrastruktur-Monitoring (CPU, Speicher, Festplatte, Netzwerk), Application-Level Health Checks, Eskalationsverfahren bei Schwellenwertüberschreitungen
• DR-Tests — Dokumentierte Tabletop-Übungen oder Live-Failover-Tests, die mindestens jährlich durchgeführt werden, mit aufgezeichneten Ergebnissen und behobenen Lücken
• Backup-Verifizierung — Wiederherstellungstests nach einem definierten Zeitplan, um zu validieren, dass Backup-Daten vollständig und wiederherstellbar sind

Verarbeitungsintegrität

Verarbeitungsintegrität befasst sich damit, ob die Systemverarbeitung vollständig, gültig, korrekt, zeitgerecht und autorisiert ist. Dieses Kriterium bezieht sich auf die Datenkorrektheit — die Sicherstellung, dass Ihr System das tut, was es mit den durchlaufenden Daten zu tun vorgibt.

Was es abdeckt

• Vollständigkeit — Alle Transaktionen, die verarbeitet werden sollten, werden verarbeitet, ohne dass welche fehlen oder dupliziert werden
• Gültigkeit — Dateneingaben entsprechen definierten Akzeptanzkriterien
• Genauigkeit — Die Verarbeitung erzeugt bei den gegebenen Eingaben das korrekte Ergebnis
• Zeitgerechtheit — Die Verarbeitung erfolgt innerhalb der erwarteten Zeitrahmen
• Autorisierung — Nur genehmigte Transaktionen werden verarbeitet

Wann Verarbeitungsintegrität einbezogen werden sollte

Beziehen Sie Verarbeitungsintegrität ein, wenn:

• Ihr SaaS-Produkt Finanztransaktionen, Abrechnungsberechnungen oder Zahlungsverarbeitung durchführt
• Sie Datentransformationen, Aggregationen oder Berechnungen durchführen, auf die Kunden für Geschäftsentscheidungen angewiesen sind
• Sie Datenpipelines betreiben, bei denen Genauigkeit kritisch ist (ETL-Prozesse, Analytics, Reporting)
• Ihre Kunden finanziellen oder betrieblichen Schaden erleiden würden, wenn Ihr System falsche Ergebnisse liefert

SaaS-Beispiel: Ein Gehaltsabrechnungs-SaaS muss Verarbeitungsintegrität nachweisen, da Berechnungsfehler direkt die Mitarbeitervergütung betreffen. Ein Prüfer wird die Eingabevalidierung testen (werden Gehaltseingaben plausibilitätsgeprüft?), die Verarbeitungsgenauigkeit (liefert der Steuerberechnungsmotor korrekte Ergebnisse für verschiedene Szenarien?) und die Abgleichskontrollen (werden Ausgabensummen mit Eingabesummen verglichen?).

Kontrollen im Detail

• Eingabevalidierung — Automatisierte Prüfungen von Datenformat, Wertebereich und Vollständigkeit vor Verarbeitungsbeginn
• Verarbeitungsüberwachung — Automatische Alerts, wenn Verarbeitungsaufträge fehlschlagen, unerwartete Ergebnisse liefern oder Zeitschwellenwerte überschreiten
• Abgleich — Systematischer Vergleich von Ein- und Ausgabedaten zur Erkennung von Diskrepanzen
• Fehlerbehandlung — Definierte Verfahren zur Identifizierung, Protokollierung und Behebung von Verarbeitungsfehlern, einschließlich Kundenbenachrichtigung, wo zutreffend
• Transaktionsprotokollierung — Unveränderliche Audit-Trails, die aufzeichnen, was verarbeitet wurde, wann, von wem und mit welchem Ergebnis

Vertraulichkeit

Das Vertraulichkeitskriterium schützt Informationen, die als vertraulich eingestuft sind. Dies ist breiter als nur personenbezogene Daten — es umfasst alle Informationen, die Ihre Organisation oder Ihre Kunden als zugriffsbeschränkt identifiziert haben.

Was es abdeckt

• Datenklassifizierung — Formelle Kategorisierung von Informationen nach Sensibilität
• Zugriffsbeschränkungen — Beschränkung des Zugangs zu vertraulichen Informationen basierend auf Rolle und Need-to-know
• Verschlüsselung — Schutz vertraulicher Daten im Ruhezustand und bei der Übertragung
• Sichere Entsorgung — Sicherstellung, dass vertrauliche Daten zerstört werden, wenn sie nicht mehr benötigt werden
• Offenlegungskontrollen — Verwaltung, wie und wann vertrauliche Informationen extern geteilt werden

Wann Vertraulichkeit einbezogen werden sollte

Beziehen Sie Vertraulichkeit ein, wenn:

• Sie Geschäftsgeheimnisse, geistiges Eigentum oder proprietäre Geschäftsinformationen Ihrer Kunden verarbeiten
• Kunden Finanzdaten, strategische Pläne oder andere sensible Geschäftsinformationen über Ihre Plattform teilen
• Ihre Verträge oder NDAs ausdrücklich verlangen, dass Sie die Vertraulichkeit von Kundendaten schützen
• Sie Daten speichern, deren Offenlegung Ihren Kunden Wettbewerbsnachteile bringen würde

SaaS-Beispiel: Ein SaaS für Rechtsdokumentenmanagement speichert Kundenverträge, M&A-Dokumente und Prozessunterlagen. Das Vertraulichkeitskriterium weist nach, dass diese Daten klassifiziert, im Ruhezustand verschlüsselt (AES-256), nur autorisierten Benutzern zugänglich und bei Kontokündigung des Kunden sicher gelöscht werden.

Vertraulichkeit vs. Datenschutz

SaaS-Teams verwechseln oft diese beiden Kriterien. Die Unterscheidung ist wichtig:

• Vertraulichkeit schützt Informationen, die von der Organisation oder dem Kunden als vertraulich eingestuft wurden — Geschäftsgeheimnisse, Finanzprognosen, Geschäftspläne, Quellcode usw.
• Datenschutz regelt speziell personenbezogene Daten — Namen, E-Mail-Adressen, Sozialversicherungsnummern, Gesundheitsdaten, Verhaltensdaten usw.

Ein SaaS-Unternehmen, das sowohl Geschäftsdokumente als auch personenbezogene Daten speichert, benötigt möglicherweise beides. Ein SaaS-Unternehmen, das nur Geschäftsdaten verarbeitet (z. B. ein Code-Repository), benötigt möglicherweise Vertraulichkeit, aber nicht Datenschutz.

Kontrollen im Detail

• Datenklassifizierungsrichtlinie — Formelles Framework, das Sensibilitätsstufen definiert (z. B. Öffentlich, Intern, Vertraulich, Eingeschränkt) und die Handhabungsanforderungen für jede Stufe
• Verschlüsselung im Ruhezustand — AES-256 oder gleichwertig für gespeicherte vertrauliche Daten, mit Schlüsselverwaltungsverfahren
• Zugriffskontrollen — Rollenbasierter Zugriff mit vierteljährlichen Zugriffsüberprüfungen, um sicherzustellen, dass nur aktuelles, autorisiertes Personal auf vertrauliche Daten zugreifen kann
• Sichere Entsorgung — Kryptografische Löschung oder zertifizierte Vernichtung, wenn Daten nicht mehr benötigt werden, mit dokumentiertem Nachweis der Durchführung
• Lieferantenkontrollen — Sicherstellung, dass Unterauftragsverarbeiter, die Ihre vertraulichen Daten verarbeiten, gleichwertigen Schutz gewährleisten

Datenschutz

Das Datenschutzkriterium regelt, wie personenbezogene Daten erhoben, genutzt, aufbewahrt, offengelegt und entsorgt werden. Es ist das operativ komplexeste Kriterium und überschneidet sich erheblich mit Vorschriften wie der DSGVO, dem CCPA und anderen Datenschutzgesetzen.

Was es abdeckt

Das Datenschutzkriterium ist nach den Generally Accepted Privacy Principles (GAPP) des AICPA organisiert:

• Benachrichtigung — Bereitstellung klarer Datenschutzhinweise über Datenerhebung und -nutzung
• Wahlmöglichkeit und Einwilligung — Gewährung von Wahlmöglichkeiten für Einzelpersonen, wie ihre Daten verwendet werden
• Erhebung — Begrenzung der Datenerhebung auf das für die genannten Zwecke Notwendige
• Nutzung, Aufbewahrung und Entsorgung — Verwendung personenbezogener Daten nur für die genannten Zwecke, Aufbewahrung nur so lange wie nötig und sichere Entsorgung
• Zugang — Ermöglichung des Zugangs zu und der Korrektur personenbezogener Daten für Einzelpersonen
• Weitergabe an Dritte — Begrenzung und Kontrolle der Weitergabe personenbezogener Daten
• Sicherheit für den Datenschutz — Schutz personenbezogener Daten vor unbefugtem Zugriff
• Qualität — Pflege korrekter, vollständiger und relevanter personenbezogener Daten
• Überwachung und Durchsetzung — Überwachung der Einhaltung von Datenschutzrichtlinien und Bearbeitung von Beschwerden

Wann Datenschutz einbezogen werden sollte

Beziehen Sie Datenschutz ein, wenn:

• Ihr SaaS-Produkt personenbezogene Daten von Endnutzern erhebt oder verarbeitet (insbesondere von Verbrauchern)
• Sie sensible personenbezogene Datenkategorien verarbeiten (Gesundheit, Finanzen, Kinderdaten, Biometrie)
• Sie in Rechtsordnungen mit strengen Datenschutzvorschriften tätig sind (EU/EWR, Kalifornien, Brasilien)
• Ihre Kunden erwarten, dass Sie Datenschutzkontrollen als Teil Ihrer Compliance-Haltung nachweisen
• Sie personenbezogene Daten im Auftrag von Kunden verarbeiten (Auftragsverarbeiter-Rolle unter der DSGVO)

SaaS-Beispiel: Eine Customer-Engagement-Plattform, die Nutzerverhaltensdaten, E-Mail-Adressen und demografische Informationen der Endnutzer ihrer Kunden erhebt, benötigt Datenschutzkontrollen. Der Prüfer wird testen, ob Datenschutzhinweise veröffentlicht und korrekt sind, ob Einwilligungsmechanismen korrekt funktionieren, ob Betroffenenauskunftsanfragen innerhalb regulatorischer Fristen erfüllt werden können und ob Aufbewahrungsrichtlinien durchgesetzt — nicht nur dokumentiert — werden.

Verhältnis zur DSGVO und anderen Vorschriften

Das Datenschutzkriterium in SOC 2 ist kein Ersatz für DSGVO-Compliance, aber es gibt erhebliche Überschneidungen. SaaS-Unternehmen, die Datenschutzkontrollen für SOC 2 implementieren, werden feststellen, dass sie gut für die DSGVO-Compliance aufgestellt sind, und umgekehrt. Wichtige Überschneidungsbereiche umfassen Datenminimierung, Einwilligungsverwaltung, Betroffenenrechte und Meldepflichten bei Datenschutzverletzungen. Weitere Details finden Sie in unserem umfassenden DSGVO-Compliance-Leitfaden.

Kontrollen im Detail

• Datenschutzhinweis — Veröffentlichte, korrekte Beschreibung der Datenerhebungspraktiken, zugänglich vor oder zum Zeitpunkt der Erhebung
• Einwilligungsmechanismen — Granulare Opt-in-/Opt-out-Kontrollen mit Aufzeichnungen darüber, wann und wie die Einwilligung erteilt wurde
• Datenminimierung — Prozesse, die sicherstellen, dass nur notwendige personenbezogene Daten erhoben werden, mit regelmäßigen Überprüfungen zur Identifizierung und Eliminierung unnötiger Datenerhebung
• Aufbewahrungsrichtlinien — Definierte Aufbewahrungsfristen nach Datenkategorie mit automatisierter Durchsetzung (Löschung oder Anonymisierung) bei Fristablauf
• Betroffenenrechte — Operative Prozesse zur Bearbeitung von Zugangs-, Korrektur-, Lösch- und Portabilitätsanfragen innerhalb der vorgeschriebenen Fristen
• Weitergabe an Dritte — Verträge und technische Kontrollen, die regeln, wie personenbezogene Daten an Unterauftragsverarbeiter und Partner weitergegeben werden

So wählen Sie Ihre Kriterien aus: Ein Entscheidungsframework

Die Auswahl der richtigen TSC-Kombination ist eine strategische Entscheidung, keine Checkbox-Übung. Hier ist ein praktisches Framework für SaaS-Unternehmen:

Schritt 1: Beginnen Sie mit Sicherheit (Pflicht)

Jeder SOC 2 Bericht enthält Sicherheit. Hier ist keine Entscheidung nötig. Konzentrieren Sie Ihre Planungsenergie auf die Common Criteria Kontrollen und stellen Sie sicher, dass die grundlegenden Kontrollen vorhanden sind.

Schritt 2: Bewerten Sie Verfügbarkeit

Fragen Sie sich: Haben wir SLAs? Sind Kunden für ihren täglichen Betrieb auf unsere Uptime angewiesen? Würde Downtime den Kunden direkten finanziellen Schaden zufügen?

Wenn die Antwort auf eine dieser Fragen Ja lautet — und das schließt nahezu jedes B2B-SaaS-Produkt ein — fügen Sie Verfügbarkeit hinzu. Der Mehraufwand ist moderat, da viele Verfügbarkeitskontrollen sich mit Sicherheitskontrollen überschneiden (Monitoring, Incident Response, Backup).

Schritt 3: Bewerten Sie Vertraulichkeit

Fragen Sie sich: Speichern wir sensible Geschäftsinformationen von Kunden? Unterliegen wir NDAs, die nachweisbaren Datenschutz erfordern? Würde die unbefugte Offenlegung von Kundendaten Wettbewerbsschäden verursachen?

Wenn Ihr SaaS mehr als generische, nicht-sensible Daten verarbeitet, ist Vertraulichkeit eine starke Ergänzung. Es signalisiert Kunden, dass Sie den Datenschutz über die Grundlinie hinaus ernst nehmen.

Schritt 4: Bewerten Sie Verarbeitungsintegrität

Fragen Sie sich: Umfasst unser Kernprodukt Berechnungen, Finanzverarbeitung oder Datentransformationen? Würde fehlerhafte Verarbeitung den Kunden finanziellen oder betrieblichen Schaden zufügen?

Wenn Ihr SaaS primär ein Datenspeicher- oder Kollaborationstool ist, ist Verarbeitungsintegrität möglicherweise nicht erforderlich. Wenn Sie Berechnungen, Aggregationen oder Finanzverarbeitung durchführen, ist es unerlässlich.

Schritt 5: Bewerten Sie Datenschutz

Fragen Sie sich: Erheben oder verarbeiten wir personenbezogene Daten von den Endnutzern unserer Kunden? Unterliegen wir der DSGVO, dem CCPA oder ähnlichen Vorschriften? Sind personenbezogene Daten zentral für die Funktionalität unseres Produkts?

Datenschutz fügt die meiste operative Komplexität hinzu. Beziehen Sie es ein, wenn die Verarbeitung personenbezogener Daten zentral für Ihr Produkt ist. Wenn Sie primär Geschäftsdaten mit minimalen personenbezogenen Informationen verarbeiten, können Sie Datenschutz möglicherweise auf einen zukünftigen Audit-Zyklus verschieben.

Gängige TSC-Kombinationen nach SaaS-Typ

SaaS-Typ	Empfohlene Kriterien	Begründung
B2B Projektmanagement / Kollaboration	Sicherheit + Verfügbarkeit	SLA-getriebener Kernservice; minimale Finanzverarbeitung oder personenbezogene Daten
B2B Analytics / BI-Plattform	Sicherheit + Verfügbarkeit + Vertraulichkeit	Verarbeitet sensible Geschäftsdaten; Kunden erwarten Vertraulichkeitskontrollen
Zahlungsverarbeitung / FinTech	Sicherheit + Verfügbarkeit + Verarbeitungsintegrität + Vertraulichkeit	Finanzberechnungen erfordern Verarbeitungsintegrität; verarbeitet sensible Finanzdaten
HR- / Recruiting-Plattform	Sicherheit + Verfügbarkeit + Vertraulichkeit + Datenschutz	Umfangreiche Verarbeitung personenbezogener Daten; unterliegt Vorschriften für Beschäftigtendaten
Verbraucherorientiertes SaaS mit B2B-Layer	Sicherheit + Verfügbarkeit + Datenschutz	Personenbezogene Daten von Endverbrauchern stehen im Mittelpunkt des Produkts
Healthcare-SaaS	Alle fünf Kriterien	Regulatorische Anforderungen berühren jedes Kriterium; Patientendaten erfordern maximale Abdeckung

Was das bedeutet: Die meisten B2B-SaaS-Unternehmen landen bei Sicherheit + Verfügbarkeit + Vertraulichkeit als Startkombination. Dies deckt die Kontrollen ab, die Enterprise-Käufer am häufigsten bewerten, und hält den Audit-Umfang für ein erstes Engagement handhabbar.

Wie GRCTrail hilft

Die Navigation durch die Trust-Service-Kriterien wird mit dem richtigen Tooling erheblich einfacher:

• Kriterien-Mapping-Engine — GRCTrail ordnet Ihre bestehenden Kontrollen jeder TSC-Kategorie zu und zeigt Ihnen genau, wo Sie Abdeckung haben und wo Lücken bestehen
• Vorgefertigte Kontroll-Frameworks — Starten Sie mit SOC 2-konformen Kontrollvorlagen für alle fünf Kriterien, angepasst an SaaS-Umgebungen
• Gap-Analyse-Dashboard — Visuelle Darstellung Ihrer Bereitschaft für jedes ausgewählte Kriterium mit priorisierten Empfehlungen zur Behebung
• Automatisierung der Nachweissammlung — Kontinuierliche Nachweiserfassung, die auf spezifische TSC-Fokuspunkte abgebildet ist, damit Sie jederzeit audit-bereit sind
• Prüfer-Kollaborationsportal — Teilen Sie Ihre Kontrolldokumentation, Nachweise und Systembeschreibung direkt mit Ihrem Prüfer über eine strukturierte Oberfläche
• Framework-übergreifendes Mapping — Sehen Sie, wie Ihre SOC 2 Kontrollen auf DSGVO, ISO 27001 und andere Frameworks abgebildet werden, die Sie möglicherweise adressieren müssen

Verwandte Leitfäden

• SOC 2 Common Criteria: CC1 bis CC9 verstehen
• SOC 2 Type I vs. Type II: Unterschiede, Kosten und Entscheidungshilfe
• Der SOC 2 Audit-Prozess: Zeitplan, Schritte und was Sie erwartet
• SOC 2 Nachweissammlung: Was Prüfer sehen möchten

Starten Sie mit GRCTrail →