ISO 27001 Control A.7.1.1 and Background Checks: What Auditors Want to See
With the updated ISO/IEC 27001:2022 and the revised Annex A, the control architecture of the standard was fundamentally restructured. While the old ISO 27001:2013 version mapped personnel security in Annex A.7.1.1, the topic in the 2022 version appears under the new numbering Annex A.6.1 (Screening) in the chapter “People Controls”. In practice, however, the old designation “A.7.1.1” has remained in audit language — auditors, certifiers and ISMS managers still talk about “A.7.1.1”, even though the standard text strictly speaking calls for A.6.1. For clarity in this article, we use both terms synonymously.
What the control materially requires, how auditors assess it, and which interfaces exist with revDSG, DSG Austria, NIS2 and DORA are shown from the perspective of a company that wants to retain certification — not achieve it for the first time. The differences are notable: anyone undergoing a recertification audit does not need to prove the setup of a screening process, but rather its practical application.
The standard text in detail: What A.6.1 / A.7.1.1 exactly requires
The wording of Annex A.6.1 ISO/IEC 27001:2022 is concise: “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.”
Four elements are relevant for audit purposes:
All candidates: The control applies to all personnel — permanent employees, temporary workers, freelancers, interns. The common practice of limiting it to permanent employment is non-compliant with the standard and is regularly raised as a “minor non-conformity” in stage 2 audits.
Prior to joining and ongoing: The check takes place before employment begins and on an ongoing basis. The ISO 27001:2022 version has strengthened the “ongoing” aspect compared with the 2013 version and has therefore moved closer to DORA Art. 5 and NIS2 Art. 21 para. 2 lit. i.
Applicable laws, regulations and ethics: The check must be legally compliant — especially under employment and data protection law. In the EU this is GDPR, in Switzerland revDSG, in Austria DSG.
Proportional to business requirements, classification and perceived risks: The depth of the check must be aligned with the protection needs of the information accessible. An admin with root access must not be hired under the same screening criteria as a receptionist.
The corresponding guidance passages are found in ISO/IEC 27002:2022, Clause 6.1, which serves as an authoritative interpretation aid. The recommendations there (identity verification, CV plausibility checks, references, education/professional credentials, criminal record checks where permitted, financial checks for finance roles) are not normatively binding, but are used by auditors as a benchmark.
Which checks are acceptable?
Acceptable is what is documented, proportional and legally compliant. In practice, five check modules have become established, which are combined depending on the risk class of the position:
Check module | Legal basis Germany | Standard risk class | High-risk class |
|---|---|---|---|
Identity verification (ID card, cross-check) | Art. 6 para. 1 lit. b GDPR | Required | Required, with video identification |
CV check (duration, gaps) | Art. 6 para. 1 lit. b GDPR, § 26 BDSG | Required | Required, in depth |
Proof of education/certification | Art. 6 para. 1 lit. b GDPR | Recommended | Required, with third-party verification |
Criminal record certificate (§ 30 BZRG) | Consent Art. 6 para. 1 lit. a GDPR or § 32 BDSG | Optional | Required |
Sanctions list screening (EU, UN, OFAC) | Art. 6 para. 1 lit. c GDPR | Recommended | Required, ongoing |
The “credit check” known from Anglo-American practice is only permissible in Germany for relevant roles (cash handling, treasury, power of attorney) — a blanket creditworthiness check violates § 26 BDSG and is treated as a non-conformity in the audit if there is no purpose linkage.
Documentation requirements in the ISMS
The depth of documentation is the most common audit stumbling block. A three-tier documentation framework is required:
Policy level: A written “Personnel Screening Policy” approved by management, with defined risk classes, check scope per class, responsibilities (HR, Information Security Officer, Legal) and an escalation path in case of findings.
Process level: A documented workflow with trigger (new hire, role change, periodic recertification), a checklist per risk class and retention periods. The process documentation must meet ISO 27001 Clause 7.5 (documented information).
Evidence level: A verifiable artifact for each person and each check — screening report, consent declaration, record of document review, approval decision. This evidence is requested on a sample basis during the audit.
The retention period for evidence artifacts is governed by § 26 BDSG (Germany) or Art. 6 revDSG (Switzerland) and should be as short as possible, but at least as long as necessary to defend against employment-law claims — usually three years after leaving the company, up to ten years in cases with findings.
How auditors check this
Auditors work in three steps: policy review, sample, interview. The sample size depends on company size — in mid-sized ISMS scopes, typically five to ten personnel files are reviewed, in large organizations fifteen to twenty. The sample is stratified: hires from the last 12 months, one case with a role change, one external contractor, one manager, one admin user.
Typical audit questions are:
Show me: the last five hires in roles with access to production systems. How is the screening process documented?
How is it ensured: that freelancers and temporary workers go through the same level of screening as permanent employees?
What happens: if a person moves internally into a higher risk class (e.g., from developer to DevOps admin)? Is there a rescreening obligation?
How do you handle: findings in screening (e.g., a gap in the CV, an entry in the criminal record certificate, a hit in sanctions list screening)?
Where is the consent: of the data subject for data processing documented? Can it be withdrawn?
Typical findings are — in order of frequency: (1) missing screening documentation for external workers, (2) inconsistent check scope without documented risk classification, (3) missing rescreening processes for role changes, (4) consent deficiencies (text modules that do not meet GDPR transparency requirements under Art. 13), (5) retention of screening artifacts for too long.
Interfaces with A.7.1.2 and A.7.2 (ISO 27001:2013) or A.6.2 and A.6.3 (ISO 27001:2022)
The personnel security controls form a triad:
A.6.1 (formerly A.7.1.1) — Screening: checks before and during employment.
A.6.2 (formerly A.7.1.2) — Terms and conditions of employment: contractual fixation of information security obligations. Typically includes confidentiality clauses, usage rules, bring-your-own-device rules.
A.6.3 (formerly A.7.2) — Information security awareness, education and training: ongoing awareness-raising and training during the employment relationship.
These three controls are typically assessed together in the audit. Consistent documentation across all three controls (i.e., the same person appears in the screening record, the employment contract and the training record) is what auditors call a “well-integrated ISMS”.
What applies in Switzerland, Austria and across the EU?
Switzerland: ISO 27001 implementation under revDSG
In Switzerland, the revised Data Protection Act (revDSG, SR 235.1) has been in force since 1 September 2023. For background checks within ISO 27001, Art. 6 (processing principles), Art. 7 (privacy by design/by default) and in particular Art. 31 para. 2 lit. c (grounds for justification for personal data) are relevant. The Swiss specific feature lies in the handling of criminal record extracts: the criminal record extract under Art. 371 of the Swiss Criminal Code is more detailed than the German criminal record certificate and may only be used with explicit consent and a strict purpose limitation.
The relationship with the predecessor DSG and the European GDPR is clarified by the EU adequacy decision of 15 January 2024: Swiss companies can continue exchanging personal data with EU partners, but for ISO 27001 certification they must consider both revDSG and (for EU employees) GDPR in parallel. The common practice in Swiss companies of relying on the ISO 27001 certifier SQS or SGS means that the audit places particular focus on revDSG compliance.
Austria: DSG and labor-constitutional law
In Austria, the Data Protection Act (DSG, BGBl. I No. 165/1999 as amended) supplements the GDPR with national special provisions. Relevant for background checks are § 11 DSG (use of data on criminal convictions) and the labor-constitutional dimension under § 96a ArbVG, according to which control measures affecting human dignity require the consent of the works council.
In practical terms, this means that an Austrian company with a works council that wants to introduce systematic screening must conclude a works agreement under § 96a ArbVG. Without this agreement, screening may still be individually consentable, but it can be assessed in the ISO audit as “not systematic” and therefore as a risk. The Austrian criminal record certificate under § 10 of the Criminal Records Act is the functional equivalent of the German criminal record certificate and is subject to comparable admissibility requirements.
EU context: overlap with NIS2 and DORA
The NIS2 Directive (Directive (EU) 2022/2555) explicitly requires “security of personnel” as a risk management measure in Art. 21 para. 2 lit. i. For the sectors listed in Annex I and II (including health, transport, finance, digital services), this establishes a legal obligation that corresponds to the Article A.6.1 requirements. The German implementation through the NIS2UmsuCG (status April 2026: in the legislative process, government draft BT-Drs. 20/11254) explicitly refers to ISO 27001 as a recognized standard for fulfilling the obligation.
The DORA Regulation (Regulation (EU) 2022/2554) goes even further for financial firms: Art. 5 DORA requires a comprehensive ICT risk management framework, which in Art. 16 DORA explicitly includes a “sound human resources policy” — including background checks for ICT staff with privileged access. DORA has been directly applicable since 17 January 2025. The overlap with ISO 27001 A.6.1 is significant; financial firms that are already ISO 27001 certified meet a large part of the DORA personnel requirements, but must document the higher level of granularity (role-to-criticality mapping).
The EU AI Act (Regulation (EU) 2024/1689) rounds out the picture: Art. 10 para. 2 lit. f requires appropriate personnel qualifications of the persons entrusted with oversight of high-risk AI systems — in practice equivalent to documented pre-screening.
Concrete checklist for ISMS managers
The following checklist structures preparation for a recertification audit with a focus on A.6.1 / A.7.1.1:
Is there a current version of the “Personnel Screening Policy” (last revision within 12 months) approved in writing by management? Is it in the ISMS document register?
Does the policy contain an explicit risk classification (e.g., Standard / Enhanced / Critical) with clear criteria (data access, financial responsibility, access to customer PII)?
Are the check modules to be completed defined as mandatory for each risk class?
Does the policy explicitly extend to freelancers, temporary workers, interns and contractors with access to information assets?
Is there a rescreening process when roles change? How often is periodic rescreening carried out for high-risk positions (recommended: every 24–36 months)?
Is there GDPR-compliant consent (Art. 7 GDPR) or revDSG-compliant consent (Art. 6 revDSG) for each affected person? Is the consent revocable and the withdrawal path documented?
Are retention periods defined in writing and enforced automatically by IT (deletion run)?
Is there a documented escalation path for findings (sanctions list hit, CV gaps, criminal record entry)? Who decides? How is the decision documented?
Is the interface to A.6.2 (employment contract clauses) and A.6.3 (training/awareness) integrated into the process?
Is there an annual internal audit report that checks compliance with the policy on a sample basis?
Audit template: questions from a real assessment context
The following questions come from a real ISO 27001:2022 surveillance audit of a DACH-wide SaaS provider (April 2025, TÜV certifier, anonymized):
Question 1: “How do you ensure that your screening processes also apply to the recently acquired subsidiary in Austria? How is the works council involved there?”
Question 2: “I see a risk class ‘Critical’ with a mandatory criminal record certificate in your policy. Show me three hires in this class from the last six months and the associated criminal record certificate scan.”
Question 3: “How do you handle employees from third countries for whom a German criminal record certificate is not available? What functional equivalence check have you established?”
Question 4: “Your ongoing sanctions list screening: how often do you match against the EU consolidated sanctions list? How quickly do you escalate a potential hit?”
Question 5: “Show me the escalation case from the last 12 months: a notable finding, the decision and the documentation.”
The most common Achilles’ heel is question 5. Companies often have clean policies and processes, but no documented escalation case — which either means that no findings occurred (unlikely with samples across several hundred hires) or that findings were not documented systematically. The latter is treated as a “major non-conformity” because the effectiveness of the control cannot be demonstrated.
Conclusion: A.6.1 is not a hygiene control, but a leadership responsibility
Control A.6.1 is often underestimated in audits — supposedly an HR issue that runs “in the background”. In reality, it is one of the controls most frequently criticized, because it sits at the intersection of HR, Legal, IT Security and data protection, and siloed organizations regularly fail here. A cleanly implemented screening system with risk classification, documented GDPR/revDSG compliance, automated evidence documentation and clear escalation paths turns the control into a non-issue in the audit — and at the same time relieves NIS2 and DORA compliance programs.
Indicium Technologies operates a GDPR- and revDSG-compliant screening system for employers in the DACH region and across the EU. Our platform delivers automated identity, CV, education, criminal record and sanctions list checks with complete audit trail documentation — exactly as auditors want to see it, and compliant with the law in Germany, Austria and Switzerland.
Book a demo and we’ll show you how A.6.1 compliance works without HR overhead.
Read more — related articles
Nabil El Berr
