Annex A 6.1: Screening

Annex A 6.1: Screening requires you to define and perform proportionate background screening for people who will access your information or systems, before they start and when roles change, and to retain evidence that screening occurred and exceptions were approved. Operationalize it by setting role-based screening criteria, assigning ownership, integrating checks into hiring/contractor onboarding, and tracking completion and outcomes.

Key takeaways:

• Define screening levels by role risk (access, privileges, data sensitivity), not a one-size-fits-all check.
• Embed screening into HR and third-party onboarding so access cannot be granted before completion (or documented exception).
• Keep an auditable evidence bundle: criteria, results/attestations, approvals, exceptions, and re-screen triggers.

Annex a 6.1: screening requirement is one of the fastest ways auditors test whether your ISMS is “real” or only policy-deep. They will look for a clear rule set (who gets screened, how, and when), proof that checks happen before access, and a consistent exception process. Screening also sits at the intersection of security, HR, procurement, and legal, so it fails most often because ownership is unclear and evidence is scattered.

This control is not asking you to run the same investigation on every worker. It expects screening proportionate to risk and aligned to applicable laws, regulations, and contractual obligations. Your job as a CCO, GRC lead, or security compliance owner is to translate that expectation into: (1) a simple screening standard tied to role risk, (2) onboarding gates that prevent unscreened access, and (3) evidence that stands up in an ISO 27001 certification audit and customer due diligence. The goal is operational certainty: you can show who was screened, under what criteria, when, and what you did when results raised concerns. ¹

Regulatory text

Framework reference: ISO/IEC 27001:2022 Annex A control 6.1 implementation expectation (Screening). ¹

What the operator must do (requirement-level interpretation):

• Establish a screening approach for personnel who will have access to information and systems.
• Make screening proportionate to the role and the information security risk.
• Perform screening at the right times (typically pre-engagement; also when role risk changes).
• Handle screening in line with applicable legal and privacy constraints.
• Keep evidence that screening is performed and outcomes are handled consistently.
  ¹

Plain-English interpretation (what Annex A 6.1 is really testing)

Auditors use screening to validate three things:

1. You know which roles are risky. Your org can distinguish between low-risk roles and roles with privileged access, access to production, sensitive customer data, or security administration responsibilities.
2. You stop “access before checks.” Screening is integrated with onboarding so system access is not granted until screening completes, or an exception is documented and approved.
3. You can prove it. You retain consistent, retrievable artifacts that show screening occurred and that adjudication (pass/fail/conditional) followed a defined process.

Screening is a people risk control. Weak screening often correlates with insider risk exposure (malicious insider, coercion, fraud) and reduces your ability to defend access decisions during incident response, disciplinary actions, or contract disputes.

Who it applies to (entity and operational context)

Entities: Any organization implementing ISO/IEC 27001 (commonly service organizations) with personnel who can access information assets. ²

Operational scope (typical):

• Employees (full-time, part-time, temporary)
• Contractors and consultants (including staff augmentation)
• Interns and apprentices
• Third-party personnel administered by a third party but given your credentials, badges, VPN, or facility access
• Privileged roles (system administrators, security engineers, database admins, SRE, cloud administrators, IAM admins)
• Roles with sensitive data access (customer support with account access, finance/payroll, HR, legal)

If you allow third-party personnel to access your systems, you can meet the control either by screening them directly or by contractually requiring the third party to screen and then collecting adequate attestations and audit rights. Screening cannot be “assumed”; it must be evidenced.

What you actually need to do (step-by-step)

Step 1: Create a control card (owner, triggers, and exceptions)

Write a one-page control “runbook” that answers:

• Control objective: reduce the risk of hiring/engaging individuals who pose unacceptable information security risk.
• Control owner: usually HR + Security/GRC jointly; name a primary accountable owner.
• In-scope population: all workers and third-party personnel with access to information assets.
• Trigger events: new hire, new contractor, role change into higher risk, rehire after gap, acquisition onboarding, elevated privilege request.
• Exception rules: who can approve, what compensating controls are required, and how exceptions expire. This aligns with how auditors expect you to run Annex A controls as defined, repeatable operations rather than ad hoc actions. ²

Step 2: Define role-based screening tiers (risk-based criteria)

Create a screening matrix that maps role risk to minimum screening checks. Keep it practical and legally reviewable.

Example tiering logic (edit to match your jurisdiction and constraints):

• Tier 1 (Low risk): no system access or only public information; basic identity verification and right-to-work checks where applicable.
• Tier 2 (Standard access): corporate email, internal tools, limited customer data; identity + prior employment verification, basic criminal check where lawful.
• Tier 3 (High risk): production access, privileged admin, security role, finance/payroll, sensitive regulated data; enhanced checks (expanded verifications, sanctions/PEP where relevant to your risk model and lawful basis).
• Tier 4 (Critical trust roles): security leadership, key custodians of cryptographic material, payment operations; enhanced checks plus stricter adjudication and documented risk acceptance when issues arise.

Document:

• The criteria for each tier (what makes a role Tier 3 vs Tier 2).
• The jurisdictions covered (where checks can be performed).
• Data handling (who can see results; how you minimize and retain).
• Adjudication standards (what results trigger review, who reviews, and how decisions are recorded).

Step 3: Embed screening into onboarding so access is gated

This is the operational center of the control.

Minimum operational design:

• HR (or your staffing vendor) initiates screening at offer acceptance / engagement approval.
• IAM/IT creates accounts only after a “screening complete” status is recorded, or after a documented exception is approved.
• Badge/VPN/production access requires an additional check: the role tier must match the access being granted.

Practical gating options:

• HRIS-to-ticket integration: HRIS triggers a ticket with required screening tier; completion updates the ticket.
• IAM workflow checks: access requests must include “screening tier” and “screening completion date.”
• Joiner-mover-leaver (JML) checklist: screening is a mandatory checkbox with evidence link.

Step 4: Define an exception and adverse finding workflow

You need a consistent approach for:

• Incomplete checks: start date is earlier than screening completion.
• Adverse findings: results require adjudication.
• Jurisdictional limitations: screening cannot be performed the same way in all countries.

Your workflow should include:

• Decision authority (HR, Legal, Security, and the hiring manager)
• Documentation requirements (what was found, what was considered, decision and rationale)
• Compensating controls (reduced access, increased monitoring, probationary restrictions, dual approval for sensitive actions)
• Time bounds (exceptions expire or convert to standard once screening completes)

Step 5: Contract for screening where third parties provide the people

For contractors provided by a third party:

• Add contractual clauses that require screening commensurate with role risk.
• Require written attestation of completion for individuals assigned to you.
• Reserve audit rights or provide a method for verification during due diligence.

This becomes critical when the third party is the “employer of record” and holds the underlying screening records that you cannot store directly for privacy reasons.

Step 6: Run recurring control health checks

Screening controls fail quietly: missing evidence, inconsistent application, role changes not captured, exceptions never closed.

Establish a light but repeatable health check:

• Sample recent joiners/movers for proof of screening tier and completion before access.
• Review privileged access grants for screening alignment.
• Verify exceptions are approved and closed. Track findings to closure with owners and due dates. ²

Required evidence and artifacts to retain (minimum evidence bundle)

Store evidence in a restricted repository (HR/security need-to-know), but make it auditable.

Design evidence

• Screening policy/standard and role-based screening matrix
• Control card/runbook (owner, triggers, steps, exceptions)
• Data handling and retention rules for screening records
• Contracts/DPAs addenda requiring screening for third-party personnel (where applicable)

Operating evidence

• For a sample of personnel: proof of screening completion status (or attestation), date, tier, and reviewer/approver
• Onboarding/JML checklist showing screening completed before access (or exception)
• Privileged access request records with screening tier confirmation
• Exception log with approvals, compensating controls, and closure evidence
• Control health check results and remediation tickets

Avoid retaining raw background check reports unless you have a defined lawful basis and retention need. Many organizations retain a pass/fail status and adjudication notes instead, with the underlying report held by the screening provider or HR under stricter controls.

Common exam/audit questions and hangups

Expect these:

• “Show me your screening standard and how you decide what checks apply to a role.”
• “Pick five recent hires and show screening completion before system access.”
• “How do you screen contractors from third parties?”
• “What happens if screening is delayed but the hiring manager wants the person to start?”
• “How do you handle role changes into privileged access?”
• “Where is the evidence stored, who can access it, and what is your retention approach?”

Common hangup: teams can describe the process verbally but cannot produce consistent artifacts across HR, IT, and security tickets.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only screening. You have a policy but no gating in IAM/IT. Fix: add a hard onboarding control point where access depends on screening status.
2. No role-risk mapping. Everyone gets the same check, or decisions are ad hoc. Fix: define tiers tied to access types and data sensitivity.
3. Contractor blind spot. Contractors enter through procurement or engineering and skip HR workflows. Fix: route all non-employee access through the same JML workflow and require third-party attestations.
4. Evidence over-collection. Storing full reports broadly increases privacy risk. Fix: retain minimal necessary evidence and restrict access.
5. Exceptions without closure. “Temporary” access becomes permanent. Fix: expiry dates, periodic review, and automated reminders tied to access recertification.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this control, and ISO 27001 itself is a certification standard rather than a regulator-led enforcement regime. Your practical risk is commercial and operational: certification nonconformities, customer due diligence failures, and increased insider-risk exposure if screened access decisions cannot be demonstrated. ²

Practical execution plan (30/60/90-day)

First 30 days (stabilize and define)

• Assign a single accountable owner and confirm HR/Legal/Security roles.
• Draft the screening standard, tier matrix, and exception workflow.
• Inventory in-scope populations: employees, contractors, third-party personnel with credentials.
• Identify where evidence will live and who can access it.

By 60 days (implement gates and evidence)

• Embed screening checks into onboarding/JML checklists and ticketing.
• Add an IAM/access request field for “screening tier” and “screening completed date/status.”
• Update third-party contract language and intake checklist to require screening attestations.
• Train hiring managers and IT/IAM approvers on “no screening, no access” (or documented exception).

By 90 days (prove operation and fix gaps)

• Run a control health check on recent joiners, movers to privileged roles, and contractors.
• Close gaps: missing evidence, inconsistent tiering, weak exception documentation.
• Build a simple dashboard: joiners screened, exceptions open, privileged access screened.
• Prepare an audit-ready evidence pack with representative samples and your control narrative.

If you want the fastest audit-ready path, Daydream is typically introduced here as the system of record for the control card, evidence bundle definition, health check tracking, and remediation closure, so you can answer auditor sampling requests without pulling from multiple systems.

Frequently Asked Questions

Do we need to rescreen personnel periodically to meet Annex A 6.1?

ISO/IEC 27001 Annex A 6.1 focuses on screening tied to engagement and risk; a common operational trigger is role change into higher risk access. If you adopt periodic rescreening, document it as your standard and apply it consistently.

Can we meet the control if a third party employs the contractors?

Yes, if your contracts require appropriate screening and you collect evidence such as attestations and audit rights. Treat third-party personnel as in-scope if they receive your credentials, access your facilities, or handle your sensitive information.

What evidence is “enough” if we cannot store background check reports?

Retain a completion status, date, screening tier applied, and the approver/adjudicator decision, plus a link or reference to where the underlying report is held under restricted access. Auditors usually want proof the control operated, not the raw report in a shared folder.

What’s the cleanest way to enforce “screen before access” in practice?

Put the gate in IAM/access request workflows and JML checklists so account creation and privileged access approvals require a screening-complete status. Back it with an exception process that requires documented approval and compensating controls.

How should we handle adverse findings without creating discrimination risk?

Define adjudication criteria with HR and Legal, keep decisions consistent, and document the job-related rationale tied to role risk and access. Restrict who can see details, and store only what you need for auditability and governance.

Does Annex A 6.1 apply to internal transfers and promotions?

Yes, when the move changes risk, such as adding privileged access or access to sensitive datasets. Treat “movers” as a trigger event and require screening tier reassessment before granting new access.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview