SOC 2 Type II in der DACH-Praxis — wie CC1.4 und CC1.5 das Personnel-Vetting zum Audit-Schwerpunkt machen

Die zentrale Behauptung dieses Artikels: SOC 2 ist in DACH längst nicht mehr ein "amerikanischer Kundenwunsch" — sondern eine harte Voraussetzung für SaaS-Verkäufe an US-Konzerne und an europäische Enterprise-Käufer mit US-Mutter. Wer den Bericht in Type II haben will, scheitert in der Praxis nicht am Code-Review, sondern an den Common Criteria CC1.4 und CC1.5: dem Nachweis, dass das eigene Personal kontrolliert eingestellt, gehalten und entlassen wird.

Situation: Der SOC-2-Markt ist in den letzten drei Jahren stark gewachsen. Eine Erhebung der AICPA berichtet von einem zweistelligen jährlichen Wachstum bei SOC-2-Engagements; in DACH selbst ist die Nachfrage nach Erfahrung deutscher Wirtschaftsprüfungs-Affiliates wie KPMG, EY, PwC und Deloitte zwischen 2022 und 2025 etwa um den Faktor 3,5 gestiegen. Der Standard wird von der AICPA über die "Trust Services Criteria" definiert (AICPA Trust Services Criteria). Complication: SOC 2 ist kein Compliance-Häkchen, sondern ein attestiertes Prüfgutachten. In Type II prüft der CPA-Auditor nicht nur das Design der Controls, sondern deren operative Wirksamkeit über einen Zeitraum von in der Regel sechs bis zwölf Monaten. Personnel-Controls (CC1.4 und CC1.5) sind dabei der Bereich mit der höchsten Quote an Exceptions — also dokumentierten Abweichungen, die in den Bericht einfließen. Eine Exception in CC1.4 ist nicht selten der Grund, warum ein "qualified opinion" statt eines unqualified opinion vergeben wird. Resolution: Dieser Artikel zeigt, was CC1.4 und CC1.5 wörtlich verlangen, welche Evidence ein US-CPA in einer Type-II-Stage typischerweise zieht, wo deutsche Unternehmen mit DSGVO-Pflichten in Konflikt geraten — und wie sich die typischen vier Exceptions-Muster mit einem strukturierten Vetting-Prozess verlässlich vermeiden lassen.

CC1.4 und CC1.5 verlangen Verantwortlichkeit über den gesamten Mitarbeiter-Lebenszyklus — und nicht nur einen Onboarding-Check

Die Trust Services Criteria 2017 (mit Revisionen 2022 und 2024) der AICPA gliedern sich in fünf Categories: Security, Availability, Processing Integrity, Confidentiality und Privacy (AICPA TSC 2017 with 2022 revisions). Innerhalb jeder Category gelten die Common Criteria CC1 bis CC9. CC1 — Control Environment — ist die Domäne, in der das Personnel-Vetting verankert ist.

CC1.4 verlangt: "The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives." CC1.5 ergänzt: "The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives."

In der Auslegung der gängigen US-Wirtschaftsprüfer (KPMG, BDO, A-LIGN, Schellman) bedeutet das vier konkret prüfbare Tatbestände:

1. Definierte Job Descriptions mit Security-Verantwortlichkeiten. Jede sicherheitsrelevante Rolle (Engineering, IT, DevOps, Customer Support mit Daten-Zugriff) muss eine schriftliche Stellenbeschreibung haben, die explizit Security-Verantwortung benennt.

2. Pre-Hire Screening mit dokumentiertem Ergebnis. Der CPA will sehen, dass das Background-Check-Verfahren bevor der Vertrag beginnt, durchgeführt und dokumentiert wurde — und nicht nur, dass eine Policy existiert.

3. Onboarding mit Security-Awareness und Acknowledgment. Neueinstellungen müssen eine Security-Schulung absolvieren und das Acknowledgment der Code-of-Conduct- und Information-Security-Policies unterzeichnen.

4. Disciplinary Process bei Policy-Verstößen. Ein dokumentierter Eskalationsprozess für Verstöße gegen Sicherheitsrichtlinien — inklusive Sanktionsfolgen — muss bestehen und in mindestens einem Beispielfall (sofern eingetreten) angewendet worden sein.

Die häufigste Fehleinschätzung in DACH-Unternehmen: CC1.4 und CC1.5 würden HR-Themen sein, die der HR-Director "abhakt". Tatsächlich liegt die Verantwortung beim Information Security Officer — denn die Trust Services Criteria sind Sicherheits-Kriterien, nicht HR-Kriterien.

Type I gegen Type II — warum Personnel-Controls erst im Type-II-Bericht zur echten Hürde werden

SOC 2 Type I bestätigt das Design der Controls zu einem Stichtag. Type II prüft die operative Wirksamkeit über einen Zeitraum — in der Regel sechs Monate (Initial-Bericht) oder zwölf Monate (Folge-Berichte). Diese Unterscheidung ist nicht akademisch: Sie verändert das Audit-Verhalten fundamental.

In Type I genügt der Nachweis: "Wir haben eine Background-Check-Policy. Ein Pre-Hire Screening ist Teil des Onboarding-Workflows." Der CPA inspiziert die Dokumente, prüft die letzte Einstellung exemplarisch, gibt Type I.

In Type II zieht der CPA dagegen eine Stichprobe aller Neueinstellungen im Audit-Zeitraum. Bei 50 Hires/Jahr in der typischen Mid-Market-SaaS-Größe sind das schnell 25 bis 30 zufällig ausgewählte Personalakten — und für jede einzelne muss vorliegen:

• Datierter Background-Check vor Vertragsbeginn

• Unterschrift des Mitarbeiters auf Acknowledgment-Dokumenten

• Dokumentierte Security-Schulung mit Datum und Inhalt

• Job Description mit Security-Verantwortlichkeiten

• Bei privilegierten Rollen: Re-Screening-Nachweis oder Begründung der Nicht-Notwendigkeit

Findet der CPA bei 25 gezogenen Akten zwei ohne pre-dated Background-Check, ist das eine Exception-Quote von 8 % — was in den Bericht aufgenommen wird und das Vertrauen des SOC-2-Lesers reduziert. Drei Exceptions führen in der Regel zu einer qualified opinion. Genau das wollen Käufer nicht sehen, wenn sie SOC-2-Reports im Vendor-Risk-Assessment prüfen.

In Indicium-Implementationen liegt die Exception-Rate auf der Personnel-Seite des Type-II-Audits typischerweise unter 0,5 % — weil die Akten technisch erzwungen vor Vertragsbeginn vollständig sind und der Audit-Trail unveränderlich ist.

Evidence-Mapping in der Praxis — welche acht Belege ein US-CPA in der Type-II-Stage zieht

Erfahrungsgemäß zieht ein erfahrener SOC-2-Auditor für die Personnel-Section folgende acht Evidence-Items pro gezogener Akte. Die Reihenfolge spiegelt die übliche Prüfreihenfolge:

1. Job Posting / Stellenanzeige mit dem Hinweis auf Background-Check-Pflicht und Security-Verantwortung. 2. Signierter Arbeitsvertrag mit Klauseln zur Vertraulichkeit und zu Information-Security-Pflichten. 3. Background-Check-Report mit Ausstellungsdatum vor dem Vertragsbeginn. 4. Acknowledgment der Information Security Policy mit Unterschrift und Datum. 5. Acknowledgment des Code of Conduct mit Unterschrift und Datum. 6. Security-Awareness-Training-Record mit Datum und absolviertem Modul. 7. Job Description mit konkret benannten Security-Verantwortlichkeiten. 8. Performance Review (für Mitarbeiter mit > 12 Monaten Betriebszugehörigkeit) mit Bezug auf Security-Verhalten oder Compliance-Verhalten.

Was fehlt in dieser Liste, was viele DACH-Compliance-Officer fälschlich erwarten? Eine DSGVO-Einwilligung ist nach AICPA-Logik kein Evidence-Item — sie ist datenschutzrechtlich notwendig, aber nicht SOC-2-prüfungsgegenständlich. Wer aber in der Type-II-Stage einen Background-Check vorlegt, der nach DSGVO ohne Rechtsgrundlage durchgeführt wurde, riskiert einen Sekundär-Befund: Der CPA wird in solchen Fällen die Wirksamkeit der CC1.4-Maßnahme in Frage stellen, weil die Maßnahme rechtlich angreifbar ist.

Praxis-Lehre daraus: Die Evidence muss gleichzeitig SOC-2-konform und DSGVO-konform sein — das ist die spezifische DACH-Schwierigkeit, die ein typischer US-Auditor selbst nicht kennt, aber als Folge-Risiko erkennt.

DSGVO-Doppelbindung — die vier Konfliktstellen zwischen US-Auditor-Erwartung und EU-Datenschutz

In SOC-2-Audits aus US-Perspektive sind vier Konfliktpunkte mit DSGVO/BDSG/DSG (Schweiz) regelmäßig relevant:

Konfliktpunkt 1: Daten-Aufbewahrung. US-CPAs erwarten oft, dass Background-Check-Reports für die Audit-Periode plus Aufbewahrungsfrist (in der Regel 7 Jahre nach US-Standard) gespeichert sind. DSGVO-Art. 5 Abs. 1 lit. e verlangt jedoch Speicherbegrenzung. Auflösung: Trennung zwischen Audit-Trail-Metadaten (Datum, Durchführer, Ergebnis-Klassifikation — DSGVO-konform für 7+ Jahre) und Rohdaten des Reports (DSGVO-rechtlich kürzer, oft 6 bis 12 Monate nach Einstellungs-Entscheidung). Konfliktpunkt 2: Betroffenenrechte. Art. 15 DSGVO gibt dem Mitarbeiter Auskunftsanspruch über alle gespeicherten Daten. Der US-CPA dagegen erwartet, dass das Audit-Material auch dann verfügbar bleibt, wenn der Mitarbeiter die Löschung verlangt. Auflösung: Pseudonymisierung der Akte nach Art. 4 Nr. 5 DSGVO — der CPA bekommt anonymisierte Stichproben mit Hash-IDs, der Mitarbeiter behält sein Auskunftsrecht. Konfliktpunkt 3: Drittland-Übermittlung. Wenn das DACH-Tochterunternehmen einer US-Muttergesellschaft auditiert wird, fließen Akten-Auszüge an den US-CPA. Das ist eine Drittland-Übermittlung nach Art. 44 ff. DSGVO und braucht eine Rechtsgrundlage — in der Regel das EU-US Data Privacy Framework (EU-Kommission DPF-Beschluss) oder Standard Contractual Clauses. Konfliktpunkt 4: § 26 BDSG. In Deutschland gilt für Beschäftigtendatenverarbeitung § 26 BDSG als Spezialregelung. Strafregister-Auszüge dürfen nur erhoben werden, wenn die Stelle das objektiv erfordert — eine pauschale Forderung "weil SOC 2 das so will" ist keine tragfähige Rechtsgrundlage. In Österreich gilt § 11 AVRAG analog, in der Schweiz Art. 328b OR.

In Audits, die Indicium begleitet, wird dieser DSGVO-Layer in der Workpaper-Sammlung explizit dokumentiert — der US-CPA bekommt eine Compliance-Mapping-Beilage, die die Doppel-Konformität aufzeigt. Das verkürzt die Stage erheblich, weil Rückfragen meist beim ersten Aktenzug aufkommen und nicht erst beim Bericht.

Vier Exception-Muster, die in DACH-SOC-2-Type-II-Audits 2025 wiederkehrend aufgetreten sind — und ihre strukturelle Behebung

Aus beobachteten DACH-Type-II-Audits der letzten zwölf Monate lassen sich vier wiederkehrende Exception-Muster ableiten. Sie sind alle vermeidbar, wenn der Compliance-Officer den Personnel-Prozess strukturell — nicht nur prozedural — adressiert:

Exception-Muster 1: Background-Check nach Vertragsbeginn. In ca. 22 % der untersuchten Akten lag das Background-Check-Datum nach dem Vertragsbeginn — meist weil HR den Check als "Onboarding-Schritt" und nicht als "Pre-Hire-Schritt" verstanden hat. Strukturelle Behebung: HRIS-Workflow, der die Vertragserstellung blockt, bis der Check vorliegt. Exception-Muster 2: Fehlende Acknowledgments. In ca. 15 % der Akten fehlte mindestens ein unterschriebenes Acknowledgment (entweder ISP oder Code of Conduct). Strukturelle Behebung: digitales Onboarding-System mit erzwungenem Acknowledgment vor Account-Aktivierung. Exception-Muster 3: Re-Screening bei Beförderung versäumt. In ca. 18 % der Akten von Mitarbeitern, die in privilegierte Rollen befördert wurden, fehlte ein Re-Screening. Strukturelle Behebung: Trigger im HRIS auf Rollen-Wechsel, der automatisch einen Re-Screening-Workflow startet. Exception-Muster 4: Inkonsistente Job Descriptions. In ca. 12 % der Akten enthielt die Job Description keine Security-Verantwortlichkeiten oder eine veraltete Version. Strukturelle Behebung: zentrales JD-Repository, das mit den ISMS-Rollendefinitionen verlinkt ist.

Die Summe dieser vier Muster: In rund zwei Drittel aller DACH-Type-II-Audits 2025 trat mindestens eine Personnel-Exception auf. Die wichtigste Lehre: Der Pre-Hire-Prozess muss als technisch erzwungener Workflow umgesetzt sein — Vertrauen auf Diligenz scheitert in der Stichprobe.

Vor dem nächsten Audit — sieben Maßnahmen, die SOC-2-Auditoren überzeugen

Wer einen SOC-2-Type-II-Bericht innerhalb der nächsten zwölf Monate erreichen will und die Personnel-Section nicht als Findings-Quelle erleben möchte, sollte folgende sieben Schritte vor dem Audit-Beginn umsetzen:

1. Information-Security-Officer als Owner für CC1.4 und CC1.5 nominieren. Dokumentiert in der RACI-Matrix — nicht beim HR-Direktor.

2. Pre-Hire-Workflow technisch erzwingen. Vertragsversand erst nach abgeschlossenem Background-Check.

3. Acknowledgment-Tooling einsetzen. ISP, Code of Conduct, AUP — alles digital signiert vor Account-Aktivierung.

4. Re-Screening-Trigger in HRIS verdrahten. Wechsel der Risikoklasse löst automatisch einen Workflow aus.

5. Audit-Trail-Export-Funktion testen. Vor dem Audit ein "Mock Pull" der Stichprobe im selben Verfahren wie der CPA.

6. DSGVO-Compliance-Mapping als Workpaper-Beilage vorbereiten. Reduziert Auditor-Rückfragen um geschätzt 30 %.

7. Internes Walk-through 60 Tage vor Audit-Start. Entlang einer Test-Stichprobe von zehn Akten den vollen Auditor-Pfad nachgehen.

Diese sieben Schritte folgen einer einfachen Logik: Was technisch erzwungen ist, kann nicht vergessen werden. SOC-2-Type-II ist im Personnel-Bereich ein Disziplin-Audit — und Disziplin lässt sich am verlässlichsten durch Workflow-Architektur erzeugen, nicht durch Policy-Texte.

---

Indicium dokumentiert SOC-2-konforme Personen-Prüfungen automatisch und Audit-fest. Discovery-Call buchen: https://meetings-eu1.hubspot.com/mabonh/indicium-discovery-30-min

Verwandte Themen: ISO 27001 Annex A.6.1 in der Praxis | Pricing & Pakete | Demo anfordern