There is a moment in every ISO 27001 project when control A.6.1 turns from a line in the Statement of Applicability into actual work. The SoA is drafted, screening is marked applicable, a Stage 2 date is in the calendar — and nobody has written down who gets checked, how deeply, or with what evidence. The generic checklists that dominate search results number all 93 controls and end in a software demo. This one covers only the personnel-security slice, step by step, and every step produces one thing: a record an auditor can sample. It is written for teams at DACH banks, insurers, utilities and KRITIS-adjacent firms, where BDSG § 26 and the AGG set the boundary of what a check may look at.
Who this checklist is for, and what it deliberately is not
It is for the ISMS manager or CISO four to twelve weeks into implementation, with the SoA drafted and HR not yet looped in. It is also for the HR lead who receives the first auditor request and realizes the screening file does not exist yet.
It is not a full 93-control roadmap, not a policy template pack, and not a tool recommendation. No software does the compliance work for an organization; the artifacts described here are what certification audits actually sample. For the exact control wording, the numbering history and who counts as personnel, see the A.6 personnel security explainer. For what the auditor requests in the opening hour, see what ISO 27001 auditors ask for first.
The 90-minute version: what A.6.1 demands in one page
The control is one sentence with three obligations: checks happen before someone joins; they continue on an ongoing basis; and their depth is proportional to business requirements, the classification of information the person will access and the perceived risks, bounded by applicable law, regulations and ethics. Read operationally, that becomes three rules:
- Nobody receives access to in-scope systems before the check is complete — and the screening record joins the ISMS evidence trail at the same time as the access decision.
- Check depth is decided once per role, in a written matrix, not ad hoc per hire.
- The check has a documented second life: triggers for rescreening and a periodic cycle for sensitive roles.
If you can point to those three things — gate, matrix, triggers — you have the operational core of the control. The rest of this checklist builds them. For how each obligation maps to evidence records, see the ISO 27001 control-to-evidence mapping.
Step 1: Write the screening procedure
The procedure is the document auditors read first, because it tells them what to sample. At minimum it should contain:
- Scope: who counts as personnel — employees, contractors, temporary and agency staff, anyone receiving access to information or systems.
- Ownership: who runs the checks (typically HR) and who signs off the risk decision (security or ISMS).
- Depth levels: the tiers of the screening matrix, referenced by name.
- The incomplete-check path: what happens when a verification comes back incomplete — delay onboarding, restrict access or escalate, per ISO/IEC 27002:2022.
- Documentation: what a screening record contains and how long it is kept.
What auditors reject: boilerplate copied from a template, unnamed owners, “as required” without criteria, and no path for incomplete checks. A focused drafting session produces two to three pages; the sign-off loop with HR and legal takes longer than the draft itself.
Step 2: Build the role-based screening matrix
The matrix is the single most-sampled A.6.1 artifact, because it is where the control’s proportionality requirement becomes a documented decision. The standard names three sizing inputs; a working matrix turns each into a variable:
- Business requirements: which regulatory regime applies to the role (banking, insurance, energy, healthcare).
- Information classification: what data and systems the role touches.
- Perceived risks: privilege level, fraud exposure, public trust.
The typical shape is three tiers — standard, enhanced and privileged — with each tier mapping to a defined depth of checks. For the full build, worked examples and the German legality overlay per check type, see the role-based screening matrix guide. One property makes the matrix do double duty: it is the proportionality decision the ISO auditor wants to see, and the necessity documentation the data protection officer asks for per check category.
Step 3: Fix the onboarding gate
Most A.6.1 findings live at one seam: the handoff between hiring and system access. “No access before the check completes” is not an HR formality; it is a handoff between HR and IT that someone must own. Concretely: the new-joiner runbook gets a screening step before account creation, a late check delays access rather than the start date where possible, and any restricted-access phase is time-bounded and signed off.
What the auditor tests is the linkage: recent joiners, their screening records and their access grants, checked against each other. If a person’s first access predates their completed check, the gate failed regardless of what the procedure says.
Step 4: Contractors, temporary and agency staff
“All candidates to become personnel” is deliberately wider than the payroll: contractors, temporary staff and agency workers are in scope for anyone with access to information or systems. The organization cannot outsource the duty to the staffing provider. The practical pattern is a contract clause under which the provider screens against your matrix, delivers the record and reports changes — plus verification on your side, and the same access gate as for employees. Auditors sample both the clause and at least one delivered record.
Step 5: Define rescreening triggers
“On an ongoing basis” ends the one-and-done reading of the control. A documented trigger list typically covers: promotion or a move into a privileged role; a move into a finance-critical function; a change in the access class of the role; and flagged events such as a sanctions-list hit or material adverse media. Finance-critical functions additionally run on a periodic cycle rather than waiting for a trigger. Keep the list short enough to be executable: five to seven documented triggers beat twenty aspirational ones. For the difference between trigger-based rescreening and continuous monitoring, see rescreening triggers versus continuous monitoring.
Step 6: Records, retention and the evidence trail
A sampleable screening record contains: what was checked per category, against which sources, with dates; the result; the decision and who made it; and the retention clock. Retention follows purpose limitation and the deletion concept — align the screening file with HR-file practice and storage-limitation rules instead of keeping everything indefinitely. Weak evidence is a signed CV. Strong evidence is a dated record of what was checked, against which sources, leading to a documented decision with defined retention.
Producing that record class at scale — registry data, employment and education history, sanctions and adverse media, closed with a human final review — is what the Indicium report is built for. The point is not the report as a document; it is the auditable decision trail behind it.
Timeline: how long each step realistically takes
- Procedure and matrix: days of focused work, not weeks. Two to five working days produce a first defensible version; the HR and legal review loop adds calendar time.
- Per-person checks: five to ten working days for a standard package is the realistic DACH baseline. Official documents such as a certificate of conduct add their own processing time, and executive deep-checks run into weeks.
- Legacy population: per-person times apply in batches — sequence by privilege against the audit date, as covered in the legacy screening checklist.
- Reverse-plan from the Stage 2 date: gate and matrix in place well before the audit window; the sample and the access-grant mapping pulled together in the evidence pack.
For the drivers behind these durations, see how long a background check takes and the screening implementation timeline. And before the auditor arrives, run the gaps through the People-controls self-audit.
Frequently asked questions
Is A.6.1 the same control as A.7.1.1?
No. The 2013 edition numbered screening as A.7.1.1; the 2022 revision moved the People theme to A.6, where screening is simply A.6.1. Guides or policies citing A.6.1.1 or A.7.1.1 follow the older structure, while certification auditors work against the 2022 list. The subject of the control is unchanged.
Does this checklist work for a 40-person firm?
Yes. Proportionality scales: the tiers can collapse from three to two, and the procedure can be shorter, but the gate, the matrix and the documented triggers are the invariant core. Small firms fail A.6.1 for missing records, not for missing paperwork volume.
Do we need a screening platform to do this?
No. The deliverables are a procedure, a matrix and records; tooling helps produce them consistently at scale, especially when checks recur across many hires. What the auditor samples is the record quality, not the tool.
What happens if a check comes back incomplete?
ISO/IEC 27002:2022 names the options: restrict access, delay onboarding or, in the extreme case, end the engagement. What auditors look for is a defined, documented path — not improvisation on the day.
This article provides general information and does not constitute legal advice.