You built the screening process for new hires, and it works. Then the ISMS scope check reveals the obvious: most of your workforce was hired before the process existed. ISO 27001 A.6.1 does not grandfather them in — the control speaks about the organization’s personnel, not about new joiners. But screening existing staff retrospectively is legally and operationally different from screening applicants, and the difference is where most programs stall. This checklist walks the retro-screening decision end to end: who to review first, on what legal basis, how to take the works council along, and what to document so the prioritization itself survives an audit.
First: you do not need to screen everyone to the same depth
The proportionality logic from the screening matrix applies with full force here. The question for a legacy workforce is not “do we need to run checks on 400 employees?” but “which roles carry the risk that justifies a retrospective check, and in what order?” A cashier hired in 2019 and a treasury administrator hired in 2019 were hired under the same process — and are not the same risk today. Prioritize by current role and current access, not by hire date.
The prioritization pass: three questions per role
Run each legacy role class through three filters, in order:
- Access: does the role now touch critical systems, client funds, or sensitive data? A promotions manager promoted into platform administration is first-bucket.
- Regime: is the role inside a regulated perimeter — banking, insurance, energy, health — where the supervisor expects screening for fit-and-proper purposes? Regulated roles outrank unregulated ones at equal exposure.
- Trust: does the role carry signing authority, approval rights or physical access to critical sites? These map to the privileged tier in the matrix.
Roles failing all three filters fall into a review-later bucket — but “later” should be a scheduled date, not a shrug. The auditor will ask when the remaining population gets covered, and “never” is a finding.
Legal basis: why retro-screening is not the same as applicant screening
For applicants, § 26 BDSG supports the necessary checks in the hiring decision. For existing employees, the necessity argument changes shape: there is no hiring decision to serve, so the check needs a purpose of its own — typically the security of the regulated operation the employee already works in, or a contractual/collective agreement that covers it. Two practical consequences:
- For sensitive categories (certificate of conduct, credit checks where applicable, sanctions/adverse media for privileged roles), the strongest footing is usually consent anchored in a works agreement, or a works agreement that directly establishes the checks as part of the employment framework. Relying on § 26 alone for deep checks on long-tenured staff is the fragile path.
- For baseline categories (identity confirmation, qualifications, employment history), necessity from the current role’s exposure is defensible — documented per category, applied consistently.
When a legacy employee declines, the answer is not termination theatre; it is a documented risk decision — reassignment options, heightened monitoring, or accepting the residual risk in writing with the employee’s manager and security aligned. The the legality decision guide works through the per-check legal analysis; the legal basis per check category gives the baseline mapping.
Works council first, not last
Retro-screening touches the entire workforce, which is precisely the situation § 87 BetrVG was built for — and works councils treat it proportionately more seriously than applicant screening. Bring the works agreement draft before any individual approach: tiers, check types, procedure for refusals, data handling, and the rollout order. A jointly agreed rollout also removes the most common internal objection — “why me and not them?” — because the order comes from an agreed risk logic, not from a manager’s discretion. The the works-council co-determination mechanics cover the process; treat the agreement as the project’s critical path.
The rollout order that survives scrutiny
Sequence the population in waves, most-exposed first:
- Privileged and regulated: signing authority, system administration, payment approvals, fit-and-proper roles. These are also the roles whose supervisors or auditors care most, so they double as your pilot.
- Enhanced: client-facing with fiduciary duties, critical-site physical access.
- Standard: remaining roles, scheduled but not urgent.
Waves keep the project honest in three ways: capacity stays realistic (HR can actually run the checks), refusals surface while you still have leverage, and each wave’s learnings (what works council questions arise, what exception rates look like) flow into the next. Document the wave plan itself — auditors sample it as evidence that the organization thought risk-first rather than alphabetically.
What to document per employee
For each retro-screened employee, the record should carry what an auditor would ask for: the role classification and why, the check list applied, the legal basis referenced (works agreement clause, consent record, § 26 assessment), the dated check results with sources, the final decision and its reviewer, and — where applicable — the documented acceptance of residual risk for decliners. That is the same record standard as for new hires; the difference is only the legal-basis column. For the record anatomy in full, see the A.6.1 evidence expectations.
Common retro-screening mistakes
- Screening everyone identically “to be fair.” Uniformity is the opposite of proportionality; it also creates the maximum legal exposure per check.
- Running deep checks without a works agreement. The fastest way to a co-determination dispute and a stalled project.
- No refusal pathway. Employees will decline; a program without a documented response improvises under pressure.
- Treating the wave plan as internal-only. It is audit evidence — date it, version it, and keep the classification logic visible.
- Confusing retro-screening with continuous monitoring. A one-time retrospective review and an ongoing monitoring capability are different controls; the the monitoring comparison keeps them straight.
Timeline expectations
For a 100–400 person regulated firm, a realistic sequence: works agreement negotiation runs 4–10 weeks and gates everything; the privileged wave completes within 4–6 weeks after that; full coverage typically lands 3–6 months out. The implementation-timeline breakdown has the component estimates. The recurring pattern: the legal and co-determination front takes longer than the screening itself, which is why it runs first.
Frequently asked questions
Does ISO 27001 really require screening employees hired years ago?
The control requires that screening happens before employment and on an ongoing basis, proportionate to risk. For a pre-existing workforce, the auditable expectation is a risk-based coverage plan in execution — not a claim that history exempts anyone. Documented waves that are advancing satisfy this far better than a silent gap.
Can we skip retro-screening if all our legacy roles are low-risk?
If the documentation shows every unscreeened role genuinely fails the risk filters, that is a defensible position for the ISMS — with a scheduled review date. What fails is asserting it without the analysis.
What do we do if an employee refuses?
Document the refusal, offer the reassignment path where one exists, and record the residual risk decision with the responsible parties. Refusal is a data point for the risk assessment, not automatically an employment-law escalation.
How does this connect to the existing employee screening we already run?
If your pre-employment process is solid, the retro project is a bounded remediation of one population with the same record standard. Start from the the personnel-security checklist to test the new-hire path, then run the waves above against the legacy population.
This article provides general information and does not constitute legal advice.