ISO 27001 Control A.7.1.1 und Background Checks: Was Auditoren sehen wollen
Mit der Neufassung ISO/IEC 27001:2022 und dem aktualisierten Anhang A wurde die Control-Architektur der Norm grundlegend umstrukturiert. Während die alte Fassung ISO 27001:2013 in Annex A.7.1.1 die personelle Sicherheit abbildete, findet sich das Thema in der 2022er-Fassung unter der neuen Nummerierung Annex A.6.1 (Screening) im Kapitel „People Controls". In der Praxis hat sich die Alt-Bezeichnung „A.7.1.1" jedoch als Auditsprache gehalten — Auditoren, Zertifizierer und ISMS-Beauftragte sprechen weiterhin von „A.7.1.1", auch wenn der Normtext streng genommen A.6.1 verlangt. Für die Klarheit dieses Beitrags verwenden wir beide Bezeichnungen synonym.
Was die Control materiell fordert, wie Auditoren sie prüfen und welche Schnittstellen zu revDSG, DSG Österreich, NIS2 und DORA bestehen, zeigt dieser Beitrag aus der Perspektive eines Unternehmens, das die Zertifizierung halten will — nicht erstmalig erreichen. Die Unterschiede sind bemerkenswert: Wer zum Recertification Audit antritt, muss nicht die Einrichtung eines Screening-Prozesses belegen, sondern dessen gelebte Anwendung.
Der Normtext im Detail: Was A.6.1 / A.7.1.1 exakt fordert
Der Wortlaut des Annex A.6.1 ISO/IEC 27001:2022 ist knapp: „Background verification checks on all candidates to become personnel shall be carried out prior to joining the organization and on an ongoing basis taking into consideration applicable laws, regulations and ethics and be proportional to the business requirements, the classification of the information to be accessed and the perceived risks."
Vier Elemente sind auditrelevant:
All candidates: Die Control adressiert sämtliches Personal — Festangestellte, Zeitarbeitnehmer, Freelancer, Praktikanten. Die in der Praxis verbreitete Eingrenzung auf Festanstellungen ist normwidrig und wird im Stage-2-Audit regelmäßig als „minor non-conformity" beanstandet.
Prior to joining and ongoing: Die Überprüfung erfolgt vor Arbeitsbeginn und fortlaufend. Die ISO 27001:2022-Fassung hat den „ongoing"-Aspekt gegenüber der 2013er-Fassung verstärkt und ist damit näher an DORA Art. 5 und NIS2 Art. 21 Abs. 2 lit. i herangerückt.
Applicable laws, regulations and ethics: Die Prüfung muss rechtskonform sein — insbesondere arbeits- und datenschutzrechtlich. Das ist in der EU die DSGVO, in der Schweiz das revDSG, in Österreich das DSG.
Proportional to business requirements, classification and perceived risks: Die Prüftiefe muss sich am Schutzbedarf der zugänglichen Informationen orientieren. Ein Admin mit Root-Access darf nicht nach demselben Prüfraster eingestellt werden wie ein Empfangsmitarbeiter.
Die korrespondierenden Guidance-Passagen finden sich in ISO/IEC 27002:2022, Clause 6.1, die als autoritative Auslegungshilfe gilt. Die dortigen Empfehlungen (Identitätsverifikation, Lebenslaufplausibilisierung, Referenzen, Ausbildungs-/Berufsnachweise, Strafregister soweit zulässig, Finanzcheck bei Finanzfunktionen) sind zwar nicht normativ verbindlich, werden aber von Auditoren als Benchmark verwendet.
Welche Prüfungen sind akzeptabel?
Akzeptabel ist, was dokumentiert, proportional und rechtskonform ist. In der Praxis haben sich fünf Prüfbausteine etabliert, die je nach Risikoklasse der Position kombiniert werden:
Prüfbaustein | Rechtsgrundlage Deutschland | Standardrisikoklasse | Hochrisikoklasse |
|---|---|---|---|
Identitätsprüfung (Ausweis, Abgleich) | Art. 6 Abs. 1 lit. b DSGVO | Zwingend | Zwingend, mit Video-Ident |
Lebenslaufprüfung (Dauer, Lücken) | Art. 6 Abs. 1 lit. b DSGVO, § 26 BDSG | Zwingend | Zwingend, vertieft |
Ausbildungs-/Zertifikatsnachweis | Art. 6 Abs. 1 lit. b DSGVO | Empfohlen | Zwingend, mit Drittverifikation |
Führungszeugnis (§ 30 BZRG) | Einwilligung Art. 6 Abs. 1 lit. a DSGVO oder § 32 BDSG | Optional | Zwingend |
Sanktionslisten-Screening (EU, UN, OFAC) | Art. 6 Abs. 1 lit. c DSGVO | Empfohlen | Zwingend, laufend |
Das aus anglo-amerikanischer Praxis bekannte „credit check" ist in Deutschland nur bei einschlägiger Funktion (Kassentätigkeit, Treasury, Prokura) zulässig — eine pauschale Bonitätsprüfung verletzt § 26 BDSG und wird im Audit als Non-Conformity gewertet, sofern der Zweckbezug fehlt.
Dokumentations-Anforderungen im ISMS
Die Dokumentationstiefe ist der häufigste Audit-Stolperstein. Erforderlich ist ein dreifach gestaffeltes Dokumentationsgerüst:
Policy-Ebene: Eine schriftliche, vom Management freigegebene „Personnel Screening Policy" mit definierten Risikoklassen, Prüfumfängen pro Klasse, Zuständigkeiten (HR, Information Security Officer, Legal) und einem Eskalationsweg bei Auffälligkeiten.
Prozess-Ebene: Ein dokumentierter Workflow mit Trigger (neue Einstellung, Rollenwechsel, periodische Rezertifizierung), Checkliste pro Risikoklasse und Aufbewahrungsfristen. Die Prozessdokumentation muss den ISO 27001 Clauses 7.5 (documented information) genügen.
Evidence-Ebene: Pro Person und Prüfung ein nachweisbares Artefakt — Screening-Report, Einwilligungserklärung, Protokoll der Dokumentensichtung, Freigabeentscheidung. Dieser Nachweis wird im Audit stichprobenartig angefordert.
Die Aufbewahrungsfrist der Evidence-Artefakte richtet sich nach § 26 BDSG (Deutschland) bzw. Art. 6 revDSG (Schweiz) und sollte so kurz wie möglich, aber mindestens so lang wie zur Verteidigung gegen arbeitsrechtliche Ansprüche erforderlich sein — in der Regel drei Jahre nach Ausscheiden, bei Auffälligkeitsfällen bis zehn Jahre.
Wie Auditoren das prüfen
Auditoren arbeiten in drei Schritten: Policy-Review, Stichprobe, Interview. Der Stichprobenumfang hängt von der Unternehmensgröße ab — bei mittelständischen ISMS-Scopes werden typischerweise fünf bis zehn Personalakten gezogen, in großen Organisationen fünfzehn bis zwanzig. Die Stichprobe ist geschichtet: Neueinstellungen der letzten 12 Monate, ein Fall mit Rollenwechsel, ein extern Beschäftigter, eine Führungskraft, ein Admin-User.
Typische Audit-Fragen sind:
Zeigen Sie mir: die letzten fünf Einstellungen in Rollen mit Zugriff auf Produktivsysteme. Wie ist der Screening-Prozess dokumentiert?
Wie ist sichergestellt: dass Freelancer und Zeitarbeiter denselben Prüfumfang durchlaufen wie Festangestellte?
Was passiert: wenn eine Person intern in eine höhere Risikoklasse wechselt (z. B. vom Entwickler zum DevOps-Admin)? Gibt es eine Re-Screening-Pflicht?
Wie gehen Sie um: mit Auffälligkeiten im Screening (z. B. Lücke im Lebenslauf, Eintrag im Führungszeugnis, Treffer im Sanktionslisten-Screening)?
Wo liegt die Einwilligung: der betroffenen Person zur Datenverarbeitung vor? Ist sie widerrufbar?
Typische Findings sind — nach Häufigkeit geordnet: (1) fehlende Screening-Dokumentation bei externen Mitarbeitern, (2) uneinheitlicher Prüfumfang ohne dokumentierte Risikoklassifizierung, (3) fehlende Re-Screening-Prozesse bei Rollenwechsel, (4) Einwilligungsmängel (Textbausteine, die DSGVO-Transparenzanforderungen nach Art. 13 nicht erfüllen), (5) zu lange Aufbewahrung der Screening-Artefakte.
Schnittstellen zu A.7.1.2 und A.7.2 (ISO 27001:2013) bzw. A.6.2 und A.6.3 (ISO 27001:2022)
Die Personnel-Security-Controls bilden eine Trias:
A.6.1 (vormals A.7.1.1) — Screening: Prüfung vor und während der Beschäftigung.
A.6.2 (vormals A.7.1.2) — Terms and conditions of employment: Arbeitsvertragliche Fixierung der Informationssicherheitspflichten. Enthält typischerweise Geheimhaltungsklausel, Nutzungsregeln, Bring-your-own-Device-Regelungen.
A.6.3 (vormals A.7.2) — Information security awareness, education and training: Laufende Sensibilisierung und Schulung während des Arbeitsverhältnisses.
Diese drei Controls werden im Audit typischerweise gemeinsam geprüft. Eine konsistente Dokumentation über alle drei Controls hinweg (d. h. die gleiche Person erscheint im Screening-Record, im Arbeitsvertrag und im Schulungsnachweis) ist das, was Auditoren als „well-integrated ISMS" bezeichnen.
Was gilt in der Schweiz, Österreich und EU-weit?
Schweiz: ISO 27001-Implementierung unter revDSG
In der Schweiz gilt seit 1. September 2023 das revidierte Datenschutzgesetz (revDSG, SR 235.1). Für Background Checks im Rahmen von ISO 27001 sind Art. 6 (Bearbeitungsgrundsätze), Art. 7 (Privacy by Design/by Default) und insbesondere Art. 31 Abs. 2 lit. c (Rechtfertigungsgründe bei Personendaten) einschlägig. Die schweizerische Besonderheit liegt in der Behandlung von Strafregisterauszügen: Der Strafregisterauszug nach Art. 371 StGB ist in der Schweiz detaillierter als das deutsche Führungszeugnis und darf nur mit ausdrücklicher Einwilligung und strikter Zweckbindung verwendet werden.
Das Verhältnis zum DSG-Vorgänger und zur europäischen DSGVO ist durch das EU-Angemessenheitsbeschluss vom 15. Januar 2024 geklärt: Schweizer Unternehmen können weiterhin Personendaten mit EU-Partnern austauschen, müssen aber für die ISO-27001-Zertifizierung sowohl revDSG als auch (bei EU-Beschäftigten) DSGVO parallel berücksichtigen. Die bei Schweizer Unternehmen übliche Anlehnung an den ISO-27001-Zertifizierer SQS oder SGS führt dazu, dass das Audit auf revDSG-Konformität besonderes Augenmerk legt.
Österreich: DSG und Arbeitsverfassungsrecht
In Österreich ergänzt das Datenschutzgesetz (DSG, BGBl. I Nr. 165/1999 idgF) die DSGVO um nationale Spezialregelungen. Für Background Checks einschlägig sind § 11 DSG (Verwendung von Daten über strafrechtliche Verurteilungen) sowie die arbeitsverfassungsrechtliche Dimension nach § 96a ArbVG, wonach Kontrollmaßnahmen, die die Menschenwürde berühren, der Zustimmung des Betriebsrats bedürfen.
Praktisch bedeutet das: Ein österreichisches Unternehmen mit Betriebsrat, das ein systematisches Screening einführen will, muss eine Betriebsvereinbarung nach § 96a ArbVG abschließen. Ohne diese Vereinbarung ist das Screening zwar individuell einwilligungsfähig, kann aber im ISO-Audit als „nicht-systematisch" und damit als Risiko gewertet werden. Die österreichische Strafregisterbescheinigung nach § 10 Strafregistergesetz ist der funktionale Pendant zum deutschen Führungszeugnis und unterliegt vergleichbaren Zulässigkeitsvoraussetzungen.
EU-Kontext: Schnittmenge mit NIS2 und DORA
Die NIS2-Richtlinie (RL (EU) 2022/2555) verlangt in Art. 21 Abs. 2 lit. i ausdrücklich „Sicherheit des Personals" als Risikomanagement-Maßnahme. Für die in Anhang I und II genannten Sektoren (u. a. Gesundheit, Verkehr, Finanzen, digitale Dienste) wird damit ein gesetzlicher Zwang etabliert, den Artikel-A.6.1-Anforderungen entspricht. Die deutsche Umsetzung durch das NIS2UmsuCG (Stand April 2026: im Gesetzgebungsverfahren, Regierungsentwurf BT-Drs. 20/11254) verweist explizit auf ISO 27001 als anerkannten Standard zur Pflichterfüllung.
Die DORA-Verordnung (VO (EU) 2022/2554) geht für Finanzunternehmen noch weiter: Art. 5 DORA fordert ein umfassendes ICT-Risikomanagement-Framework, das in Art. 16 DORA explizit die „sound human resources policy" umfasst — einschließlich Hintergrundprüfungen für ICT-Personal mit privilegiertem Zugang. DORA ist seit 17. Januar 2025 unmittelbar anwendbar. Die Schnittmenge mit ISO 27001 A.6.1 ist erheblich; Finanzunternehmen, die bereits ISO-27001-zertifiziert sind, erfüllen einen Großteil der DORA-Personnel-Anforderungen, müssen aber die höhere Granularität (Rolle-zu-Kritikalität-Mapping) dokumentieren.
Der EU AI Act (VO (EU) 2024/1689) rundet das Bild ab: Art. 10 Abs. 2 lit. f verlangt für Hochrisiko-KI-Systeme eine angemessene personelle Qualifikation der mit der Aufsicht betrauten Personen — in der Praxis gleichbedeutend mit einer dokumentierten Vorprüfung.
Konkrete Checkliste für ISMS-Beauftragte
Die folgende Checkliste strukturiert die Vorbereitung auf ein Recertification Audit mit Fokus A.6.1 / A.7.1.1:
Ist eine „Personnel Screening Policy" in aktueller Fassung (letzte Revision innerhalb von 12 Monaten) vom Management schriftlich freigegeben? Liegt sie im ISMS-Dokumentenregister?
Enthält die Policy eine explizite Risikoklassifizierung (z. B. Standard / Enhanced / Critical) mit klaren Kriterien (Datenzugriff, Finanzverantwortung, Kunden-PII-Zugriff)?
Sind pro Risikoklasse die zu absolvierenden Prüfbausteine verbindlich definiert?
Erstreckt sich die Policy ausdrücklich auf Freelancer, Zeitarbeitnehmer, Praktikanten und Werkvertragsnehmer mit Zugriff auf Informationswerte?
Existiert ein Re-Screening-Prozess bei Rollenwechsel? Wie häufig erfolgt periodisches Re-Screening bei Hochrisikopositionen (empfohlen: alle 24–36 Monate)?
Liegt für jede betroffene Person eine DSGVO-konforme Einwilligung (Art. 7 DSGVO) bzw. revDSG-konforme Einwilligung (Art. 6 revDSG) vor? Ist die Einwilligung widerrufbar und der Widerrufsweg dokumentiert?
Sind die Aufbewahrungsfristen schriftlich festgelegt und mit der IT automatisiert durchgesetzt (Löschlauf)?
Gibt es einen dokumentierten Eskalationsweg bei auffälligen Befunden (Sanktionslisten-Treffer, CV-Lücken, Strafregistereintrag)? Wer entscheidet? Wie wird die Entscheidung dokumentiert?
Ist die Schnittstelle zu A.6.2 (Arbeitsvertragsklauseln) und A.6.3 (Schulung/Awareness) prozessual verzahnt?
Existiert ein jährlicher internes Audit-Report, der die Einhaltung der Policy stichprobenartig überprüft?
Audit-Template: Fragen aus realem Prüfungskontext
Die folgenden Fragen stammen aus einem tatsächlichen ISO-27001:2022-Überwachungsaudit eines DACH-weiten SaaS-Providers (April 2025, TÜV-Zertifizierer, anonymisiert):
Frage 1: „Wie stellen Sie sicher, dass Ihre Screening-Prozesse auch für die kürzlich übernommene Tochtergesellschaft in Österreich gelten? Wie ist der Betriebsrat dort eingebunden?"
Frage 2: „Ich sehe in Ihrer Policy eine Risikoklasse ,Critical' mit Pflicht-Führungszeugnis. Zeigen Sie mir drei Einstellungen in dieser Klasse aus den letzten sechs Monaten und den zugehörigen Führungszeugnis-Scan."
Frage 3: „Wie handhaben Sie Mitarbeitende aus Drittstaaten, für die ein deutsches Führungszeugnis nicht verfügbar ist? Welchen funktionalen Äquivalenzcheck haben Sie etabliert?"
Frage 4: „Ihr laufendes Sanktionslisten-Screening: Mit welcher Frequenz läuft der Abgleich gegen die EU-Konsolidierte Sanktionsliste? Wie schnell eskalieren Sie einen potenziellen Treffer?"
Frage 5: „Zeigen Sie mir den Eskalationsfall der letzten 12 Monate: eine auffällige Prüfung, die Entscheidung und die Dokumentation."
Die häufigste Achillesferse ist Frage 5. Unternehmen haben oft saubere Policies und Prozesse, aber keinen dokumentierten Eskalationsfall — was entweder bedeutet, dass keine Auffälligkeiten auftraten (unwahrscheinlich bei Stichproben über mehrere hundert Einstellungen) oder dass Auffälligkeiten nicht systematisch dokumentiert wurden. Letzteres wird als „major non-conformity" gewertet, da die Wirksamkeit der Control nicht belegbar ist.
Fazit: A.6.1 ist keine Hygiene-Control, sondern eine Führungsaufgabe
Die Control A.6.1 wird in Audits oft unterschätzt — vermeintlich ein HR-Thema, das „nebenbei" mitläuft. Tatsächlich ist sie eine der am häufigsten bemängelten Controls, weil sie an der Schnittstelle zwischen HR, Legal, IT-Security und Datenschutz liegt und Silo-Organisationen daran regelmäßig scheitern. Ein sauber implementiertes Screening-System mit Risikoklassifizierung, dokumentierter DSGVO-/revDSG-Konformität, automatisierter Evidence-Dokumentation und klaren Eskalationswegen macht die Control zur Nicht-Diskussion im Audit — und entlastet zugleich NIS2- und DORA-Compliance-Programme.
Indicium Technologies betreibt ein DSGVO- und revDSG-konformes Screening-System für Arbeitgeber in der DACH-Region und EU-weit. Unsere Plattform liefert automatisierte Identitäts-, Lebenslauf-, Ausbildungs-, Strafregister- und Sanktionslisten-Prüfungen mit lückenloser Audit-Trail-Dokumentation — so, wie Auditoren sie sehen wollen, und rechtskonform in Deutschland, Österreich und der Schweiz.
Buche eine Demo und wir zeigen dir, wie A.6.1-Compliance ohne HR-Overhead funktioniert.
Weiterlesen — verwandte Artikel
Nabil El Berr
