Somewhere between the kickoff workshop and the Stage 2 audit, an auditor will ask for the document that shows why different roles receive different depths of screening. Most organizations cannot produce it. They screen everyone roughly the same way — whatever the HR process has always done — and they cannot explain the logic behind it. The screening matrix fixes that: it is the artifact where ISO 27001’s proportionality requirement stops being a sentence in the standard and becomes a documented, defensible decision. This guide builds it, including the German legality overlay that decides what each tier may actually check.
Why the matrix is the single most-sampled A.6.1 artifact
Auditors do not read screening policies for pleasure. They sample the matrix because it answers the question the control actually poses: are checks proportional to business requirements, information classification and perceived risk? A matrix makes that proportionality visible as rows and columns — role classes down the side, check types across the top, decisions in the cells. When the auditor sees the same depth applied to the receptionist and the head of trading, they write a finding: the organization has a control, but not a risk-based one.
The matrix also does double duty, which few teams realize before their data protection officer asks about it. The proportionality logic ISO wants per role is the same necessity documentation GDPR wants per check category. One artifact, two audiences. For the full control context behind this, see the A.6.1 proportionality clause in full and the step-by-step build in the personnel-security checklist.
The three inputs A.6.1 names
The standard lists three sizing inputs. A working matrix turns each into a variable:
- Business requirements: which regulatory regime applies to the role. A bank teller, an insurance claims handler and a grid-control operator sit under different supervisors with different expectations.
- Information classification: what data and systems the role touches. Client data, payment data, grid telemetry and building access are not the same exposure.
- Perceived risks: privilege level, fraud exposure and public trust. The person who can approve payments, change configurations or represent the firm carries risk even without special data access.
If your matrix cannot be traced back to these three variables for every tier boundary, expect the auditor to ask why the boundary sits where it does.
Tier design: standard, enhanced, privileged
Three tiers cover most regulated firms without over-engineering:
- Standard: everyone receiving access to information or systems. Baseline checks: identity, qualifications, employment history.
- Enhanced: roles with trust exposure — client-facing functions with fiduciary duties, staff with physical access to critical sites, anyone the regulator cares about. Adds the checks that need a role-specific justification.
- Privileged: roles with elevated access or fraud exposure — system administrators, payment approvers, executives, people with signing authority. Adds sanctions and adverse-media screening, and the deepest documentation.
Two tiers can work in a small firm; four invite unmaintained complexity. The test is not elegance but executability: HR must be able to classify every new role in minutes, and the classification must be repeatable.
Check depth per tier
The table is the matrix’s core. A workable version for a German regulated firm:
| Check category | Standard | Enhanced | Privileged |
|---|---|---|---|
| Identity | Yes | Yes | Yes |
| Qualifications | Yes | Yes | Yes |
| Employment history | Yes, last 5 years | Yes, last 10 years | Yes, last 10 years + references |
| Certificate of conduct | No | Trust-critical roles only | Yes |
| Credit check | No | Finance-relevant roles only | Finance-relevant roles only |
| Sanctions, PEP, adverse media | No | Risk-triggered only | Yes |
Two design rules keep this table defensible. First, every escalation across a row needs a justification that maps to one of the three A.6.1 inputs — not to “we’ve always done it this way.” Second, cells that say “only” or “risk-triggered” need their criterion written down somewhere, or they will be interpreted five different ways by five hiring managers.
The German legality overlay: what each check may cost
ISO 27001 sets a floor; German law sets the ceiling. Every tier decision passes through § 26 BDSG, which allows employee-data processing when it is necessary for the employment relationship — with consent as the alternative path where necessity is contested. In practice:
- Identity, qualifications, employment history: defensible for essentially every role under § 26(1). Document the necessity per category rather than per candidate.
- Certificate of conduct (§ 30 BZRG): lawful where the role justifies it — typically trust-critical positions in banking, security and care. Announce the requirement in the job posting and request the simple or extended version deliberately, not as a default.
- Credit checks: narrow. Defensible for roles with genuine financial exposure; the cash-handler-versus-controller line matters. Usually run with consent, and rarely for standard roles.
- Sanctions, PEP and adverse media: defensible for privileged and risk-triggered roles; the check belongs in the matrix with a written criterion, and results need a human final review to clear false positives.
For the legal basis per check category in depth, see the legal basis per check category; the per-check decision walkthrough is in the legality decision guide.
Worked example: a 40-person payment institution
A payment institution with 40 staff, pursuing ISO 27001, drafts its matrix as a SoA annex. The excerpt:
| Role class | Tier | Checks | Justification (SoA column) |
|---|---|---|---|
| Customer support (10) | Standard | ID, qualifications, employment history 5y | Access to client contact data; § 26(1) BDSG necessity |
| Payment operations (18) | Enhanced | Standard + certificate of conduct (trust-critical) | Execution access to payment flows; § 30 BZRG basis |
| Finance and approvals (7) | Privileged | Enhanced + credit, sanctions/adverse media | Payment approval authority; fraud exposure |
| Management (5) | Privileged | Privileged, full depth | Signing authority; regulatory fit-and-proper expectations |
The justification column is what auditors actually read. It connects each escalation to a business requirement, an information class or a perceived risk — the three inputs from the standard — and to a legal basis. When the DPO asks the same question, the answer is the same column.
Works council and § 87 BetrVG: when the matrix needs co-determination
Introducing or materially changing systematic screening typically triggers co-determination — commonly under § 87(1) No. 6 BetrVG where technical monitoring is involved, and regularly through a works agreement that fixes tiers, check types and procedure. Treat this as a design input, not an afterthought: a matrix agreed with the works council survives an auditor’s question about acceptance and consistency far better than one imposed unilaterally. The the works-council dimension covers the mechanics.
Common matrix mistakes
- One depth for all roles. It fails proportionality and wastes budget on checks nobody needed.
- Tiers that ignore privilege. The admin with production access screened like the front desk is the finding auditors write most often.
- Missing contractor columns. External staff with access belong in the same matrix, or the coverage story breaks — see Step 4 of the personnel-security checklist.
- A matrix that exists but is not applied. Consistency is sampled: if the last three hires in a tier received different checks without documented reason, the matrix is theater.
- No review rhythm. Roles change; a matrix last touched two years ago will not match today’s privilege landscape.
Keeping the matrix alive
Two mechanisms keep it current. First, an annual review plus an ad-hoc review on role changes — a move into a privileged function should trigger reclassification and, where the tier rises, rescreening. Second, a trigger list per tier: what events cause a recheck independent of the role change, from sanctions hits to material adverse media. Keep the distinction between trigger-based rescreening and continuous monitoring clear — rescreening triggers vs continuous monitoring explains when each fits.
From matrix to execution
The matrix defines depth; execution produces the records. For each tier the organization needs a documented report with dated sources, per-check results and a final human decision — and the matrix must be what those reports are measured against at the next audit. That consistency is the difference between a document and a control.
Frequently asked questions
What is the difference between the matrix and the screening policy?
The policy describes the process — who screens, when, with what responsibilities. The matrix contains the decisions: which role classes exist and what depth each receives. Auditors read the matrix first and use the policy to check that practice matches it.
How many tiers should we use?
Three works for most regulated firms: standard, enhanced, privileged. Use two if your role landscape is genuinely binary; avoid four or more unless each boundary is defensible against the three A.6.1 inputs.
Who owns the matrix?
Typically security or the ISMS function owns it, HR maintains the role classifications, and legal or the DPO validates the check list against § 26 BDSG limits. The works council is involved where co-determination applies.
How does an auditor sample the matrix?
By picking recent hires from each tier, pulling their screening records and access grants, and checking that the depth delivered matches the depth promised. Discrepancies without documented justification become findings.
This article provides general information and does not constitute legal advice.