# Personnel Screening Procedure: [Organization name] > Procedure for risk-based background verification of candidates, > employees, contractors and other personnel before they join and, where > the role requires it, at intervals afterwards. It supports ISO/IEC > 27001:2022 + Amd 1:2024, Annex A control A.6.1 (pre-employment > screening), with guidance in ISO/IEC 27002:2022, and links to A.6.2 > (security terms in employment contracts) and A.5.19 (security in > supplier relationships) for contractor screening. It sets screening > levels per role, the checks in each level, the legal limits that apply > in each jurisdiction, how adverse findings are decided and how screening > records are kept and deleted. Replace every `[bracketed]` value and > every row marked *Example*. This is a documentation format, not legal > advice: screening law differs widely between countries, and some checks > are prohibited or tightly restricted in some places. ## Document control | Field | Value | |---|---| | Document ID | DOC-ISMS-050 | | Version | [1.0] | | Status | [Draft / In review / Approved / Superseded] | | Owner | [@head-of-people] (procedure owner), [@isms-manager] (ISMS owner) | | Approvers/reviewers | [@general-counsel], [@dpo], [@ciso] | | Last updated | YYYY-MM-DD | | Classification | [Internal] | | Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024, A.6.1; guidance ISO/IEC 27002:2022 | | Countries covered | [List of countries where the organization hires or engages personnel] | | Screening provider(s) | [Internal HR / external screening provider, contract reference in DOC-ISMS-066] | | Related records | Legal register DOC-ISMS-014, records of processing [reference], DPIA [reference] | | Next scheduled review | YYYY-MM-DD (at least annually and when hiring in a new country) | ### Approvals | Role | Name | Decision | Date | |---|---|---|---| | Procedure owner (HR) | [@head-of-people] | [Prepared] | YYYY-MM-DD | | Legal counsel | [@general-counsel] | [Approved for listed countries] | YYYY-MM-DD | | Data protection officer or privacy lead | [@dpo] | [Approved] | YYYY-MM-DD | | ISMS owner | [@isms-manager] | [Approved] | YYYY-MM-DD | ### Revision history | Version | Date | Author | Change | |---|---|---|---| | 1.0 *(Example)* | YYYY-MM-DD | [@head-of-people] | First approved version for the certification audit | | 1.1 *(Example)* | YYYY-MM-DD | [@head-of-people] | Added second country to section 3.3, contractor flow-down in section 9 | ## Contents 1. Purpose and scope 2. Roles and responsibilities 3. Legal and ethical principles 4. Screening levels 5. Role-to-level mapping 6. Check catalogue 7. Screening process 8. Adverse findings and decisions 9. Contractors, agency staff and supplier personnel 10. Re-screening and role changes 11. Data protection, retention and deletion 12. Size tiers 13. Records and evidence 14. Metrics 15. References ## 1. Purpose and scope This procedure makes sure that [Organization name] verifies the background of people before they are given access to information and systems in the ISMS scope (DOC-ISMS-002), and that the depth of the verification matches the risk of the role. It applies to: - candidates for employment, including internal candidates moving into a role with a higher screening level; - contractors, consultants, interns and temporary or agency staff who receive an account, a badge or access to non-public information; - personnel of suppliers who access in-scope systems or information, by flow-down of contract requirements (section 9); - members of the board or advisory bodies who receive Confidential information, where local law allows screening of office holders. It does not cover customer identity verification, physical visitor registration (see the physical security policy, DOC-ISMS-055) or screening for purposes unrelated to information security, such as workplace safety medicals. ## 2. Roles and responsibilities | Role | Responsibility | |---|---| | HR (procedure owner) | Runs the process, holds screening records, issues the clearance outcome, keeps this procedure current | | Hiring manager | Requests the screening level when the requisition is opened, does not receive raw results | | ISMS manager | Maintains the role-to-level mapping with HR, reports metrics to management review, checks the control in internal audit planning | | Legal counsel | Confirms which checks are lawful in each country, reviews consent and notice wording, advises on adverse findings | | Data protection officer or privacy lead | Confirms legal basis, data minimisation and retention, reviews the DPIA where one is needed | | Screening provider (if used) | Performs checks under a written contract with security and privacy terms (DOC-ISMS-068) | | Supplier managers | Obtain screening attestations from suppliers whose personnel access in-scope assets | | IT service desk | Creates accounts only after HR confirms clearance in the onboarding ticket (`ops/onboarding-checklist`) | ## 3. Legal and ethical principles ### 3.1 Principles 1. **Lawful in every country.** A check is used only where it is lawful for that role in that country. Where law and this procedure differ, local law wins and the difference is recorded in section 3.3. 2. **Proportionate.** The depth of screening follows the screening level of the role, never the personal preference of a manager. 3. **Transparent.** Candidates are told before any check which checks will be done, by whom, why, and how long results are kept. 4. **Consent where required, not as a default basis.** In many jurisdictions consent in an employment context is not freely given; use the legal basis legal counsel confirms, and collect consent or written authorisation only where the law requires it (for example, some countries require written authorisation before a third-party background report is obtained). 5. **Minimal.** Collect only the result needed to decide. Do not keep copies of identity documents longer than local law requires. 6. **Fair.** Every adverse finding is assessed individually against the role (section 8), and the person can respond before a final decision. 7. **Non-discriminatory.** Screening never uses protected characteristics and is applied consistently to everyone in the same level. ### 3.2 Criminal records and other sensitive data Criminal record checks are among the most restricted checks. As an international example, Article 10 of the EU General Data Protection Regulation (Regulation (EU) 2016/679) allows processing of personal data relating to criminal convictions and offences only under the control of official authority or when authorised by EU or Member State law with appropriate safeguards. Many other countries have equivalent rules, spent-conviction regimes, "ban the box" style limits on when the question may be asked, or rules that permit checks only for listed professions. Rules for this organization: - request criminal record information only for roles mapped to a level that includes it, and only in countries listed as permitted in 3.3; - ask only at the stage of the process the law allows (often after a conditional offer); - obtain the record through the official channel for that country; - never collect health data, union membership, religion or similar categories as part of security screening. ### 3.3 Jurisdiction table | Country | Identity and right to work | References | Qualifications | Criminal record | Credit or financial | Notes and timing | Confirmed by, date | |---|---|---|---|---|---|---|---| | [Country A] *(Example)* | Permitted, mandatory | Permitted with notice | Permitted | Permitted only for listed roles, after conditional offer, official certificate | Not permitted | Notice before checks, results deleted after decision unless needed | [@general-counsel], YYYY-MM-DD | | [Country B] *(Example)* | Permitted, mandatory | Permitted with consent | Permitted | Not permitted for this sector | Permitted for finance roles only | Works council consultation required for changes | [Local counsel], YYYY-MM-DD | | [Country] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | ## 4. Screening levels | Level | Applies to | Checks (where lawful, see 3.3) | Completed before | |---|---|---|---| | S1 Baseline | All personnel with an account or access to Internal information | Identity, right to work, employment history for the last [3] years or [2] references, declared conflicts of interest | First day of access | | S2 Enhanced | Access to Confidential information, customer data, source code or finance systems | S1 plus verified professional qualifications and certifications claimed, [2] professional references including one recent manager, adverse media or sanctions list search where lawful | First day of access to the S2 assets | | S3 High trust | Privileged access to production, security tooling, key management, payment flows, OT safety systems, or bulk personal data | S2 plus criminal record check where lawful for the role, financial probity check where lawful and relevant, extended employment history for [5] years | Granting of the privileged access | Rules: - A person may start work at S1 while S2 or S3 checks are pending only if the higher-risk access is withheld until clearance and the hiring manager and HR record the decision. Track these in the pending list (section 7.3). - Where a check is not lawful in a country, the level is met by the remaining checks plus any compensating control approved by the ISMS manager (for example dual control or enhanced logging of privileged sessions, see `security/privileged-access-standard`). ## 5. Role-to-level mapping | Role family | Typical access | Level | Rationale | |---|---|---|---| | All staff not listed below *(Example)* | Corporate apps, Internal information | S1 | Baseline for everyone with an account | | Customer support *(Example)* | Customer records, support tooling | S2 | Access to customer personal data | | Software engineers *(Example)* | Source code, non-production environments | S2 | Integrity of the product and access to code | | Site reliability and platform engineers *(Example)* | Production administration, cloud root accounts | S3 | Privileged access to production and customer data | | Security team *(Example)* | Security tooling, logs, key management | S3 | Can disable controls and read sensitive logs | | Finance with payment authority *(Example)* | Payment release, bank portals | S3 | Fraud risk | | OT engineers at plants *(Example)* | Plant control systems | S3 | Safety and availability of production | ## 6. Check catalogue | Check ID | Check | How it is done | Verified when | If verification is impossible | |---|---|---|---|---| | CHK-01 | Identity | Original or certified identity document checked against the person, or a certified digital identity service | Document valid and matches the person | Do not grant access | | CHK-02 | Right to work | Check required by the law of the country of work | Check completed and recorded as the law requires | Do not grant access | | CHK-03 | Employment history | Confirm dates and role with former employers or official records | Dates match within [1] month, gaps explained | Accept a signed explanation plus an additional reference | | CHK-04 | References | Structured questions, professional referees only | Two satisfactory references | Escalate to HR lead for a decision | | CHK-05 | Qualifications and certifications | Verify with the issuing body or its public register | Claimed credential confirmed | Treat as not held, reassess suitability for the role | | CHK-06 | Conflict of interest declaration | Signed declaration at offer stage | Declaration received and reviewed | Do not grant access until received | | CHK-07 | Sanctions and adverse media | Search of official sanctions lists and public media, where lawful | No relevant match, or match cleared | Escalate to legal counsel | | CHK-08 | Criminal record | Official certificate through the national channel, where lawful | Certificate received and assessed (section 8) | Compensating control or role restriction approved by ISMS manager | | CHK-09 | Financial probity | Credit or insolvency check where lawful and relevant | Result assessed against role criteria | Compensating control (dual authorisation) | Qualification checks feed the competence records kept under clause 7.2 in the competence and training matrix (DOC-ISMS-026). ## 7. Screening process ### 7.1 Steps 1. **Requisition.** The hiring manager opens the requisition with the role family; HR sets the screening level from section 5. 2. **Notice.** HR gives the candidate the screening notice (checks, purpose, provider, retention) at the point the law allows. 3. **Checks.** HR or the provider performs the checks for the level. 4. **Assessment.** HR records each check result. Any adverse or incomplete result goes to section 8. 5. **Clearance.** HR records the outcome: Cleared, Cleared with conditions, or Not cleared. 6. **Contract and agreements.** The person signs the employment or engagement contract with security terms (A.6.2) and the confidentiality agreement (`isms/confidentiality-nda`, DOC-ISMS-051). 7. **Access.** HR confirms clearance in the onboarding ticket; only then does the service desk grant access for the level (`ops/onboarding-checklist`). ### 7.2 Flow The diagram shows the same seven steps; access is never granted on the "Not cleared" path. ```mermaid flowchart TD A["1. Requisition: role family"] --> B["HR sets screening level S1, S2 or S3"] B --> C["2. Screening notice to candidate"] C --> D["3. Checks for the level"] D --> E{"4. Any adverse or incomplete result?"} E -- No --> F["5. Cleared"] E -- Yes --> G["Section 8: individual assessment"] G --> H{"Decision"} H -- "Cleared with conditions" --> F2["5. Cleared with conditions"] H -- "Not cleared" --> X["Offer withdrawn or role changed"] F --> I["6. Contract and confidentiality agreement signed"] F2 --> I I --> J["7. HR confirms clearance in onboarding ticket"] J --> K["Access granted for the level"] ``` ### 7.3 Pending clearances When a person starts before all checks are complete, record it here and withhold the higher-level access. | Ref | Person (employee ID) | Level required | Pending check | Access withheld | Decision by | Due date | |---|---|---|---|---|---|---| | SCR-PEND-001 *(Example)* | E-1042 | S3 | CHK-08 criminal record certificate | Production admin role | [@head-of-people] and [@isms-manager] | YYYY-MM-DD | ## 8. Adverse findings and decisions An adverse finding is any result that is negative, inconsistent with what the candidate declared, or incomplete. HR assesses it with legal counsel using these criteria: - relevance of the finding to the duties and access of the role; - seriousness and age of the matter and any rehabilitation; - whether the candidate declared it when asked; - whether a condition (role restriction, supervision, dual control) would reduce the risk to an acceptable level. Before a final negative decision, give the candidate the information the law requires (in some jurisdictions a copy of the report and a period to dispute it) and an opportunity to explain. Record the decision with its reasons in the screening file, not in the general HR file. | Ref | Level | Finding (category only) | Criteria considered | Decision | Decided by | Date | |---|---|---|---|---|---|---| | SCR-ADV-001 *(Example)* | S2 | Employment dates inconsistent by 4 months | Gap explained with evidence, no relevance to risk | Cleared | [@hr-lead] | YYYY-MM-DD | | SCR-ADV-002 *(Example)* | S3 | Qualification not confirmed by issuer | Credential was a stated requirement for the role | Not cleared for this role, offered S2 role | [@hr-lead], [@general-counsel] | YYYY-MM-DD | ## 9. Contractors, agency staff and supplier personnel | Engagement type | Who screens | Minimum requirement | Evidence held by [Organization name] | |---|---|---|---| | Individual contractor engaged directly | [Organization name] HR | Same level as an employee in the same role | Screening outcome record | | Agency or temporary staff | Agency, under the agency contract | Level stated per assignment, agency confirms in writing | Agency attestation per person, right to audit | | Supplier personnel accessing in-scope systems | Supplier, under DOC-ISMS-068 | Screening equivalent to the level of the access, flowed down to subcontractors | Annual attestation, named list of personnel with access, notification of changes | | Offshore or nearshore development teams | Supplier | Level per role plus any local legal limits | Attestation and sample evidence at supplier review (`compliance/supplier-security-assessment`) | Record each supplier's screening arrangement in the supplier register (DOC-ISMS-066). ## 10. Re-screening and role changes Repeat or extend screening when: - a person moves to a role with a higher screening level (internal move, promotion or temporary assignment): perform the missing checks before the new access is granted; - the role is S3: re-screen every [3] years where lawful, or use an annual self-declaration where periodic checks are not lawful; - credible information suggests a material change (for example a new conflict of interest), handled under HR policy with legal advice; - a person returns after an absence of more than [12] months; - staff join through an acquisition: perform a gap check against this procedure within [6] months of completion and restrict privileged access until gaps are closed. ## 11. Data protection, retention and deletion - Store screening records in the HR system in a restricted area, with access limited to named HR staff and legal counsel. - Keep the **outcome record** (level, checks done, dates, outcome, decided by) for the duration of employment plus [period set by the legal register, DOC-ISMS-014]. - Keep **raw reports and certificates** only as long as needed to decide and to defend the decision, then delete them. *Example:* delete within [6] months of the decision where the law of the country permits. - Delete records of unsuccessful candidates after [period], unless legal proceedings are pending. - Apply the deletion rules of `data/data-retention-deletion-standard` and record deletions. - Screening providers process data only under a contract with data protection terms and deletion obligations. ## 12. Size tiers | Aspect | Small: Quillmere Analytics Ltd | Medium: Quillmere Health Systems | Large: Quillmere Group | |---|---|---|---| | People in scope | 46 (38 employees, 8 contractors) | 320 staff plus colocation and support suppliers | 2,400 staff at 6 sites in 4 countries | | Who runs it | Office manager with an external screening provider, ISMS manager (0.5 FTE) checks mapping | HR team with one screening coordinator | Group HR policy, country HR teams execute, CISO office owns the mapping | | Levels used | S1 and S2 for most, S3 for production admins | S1 to S3, S3 for clinical data administrators and the 3-person security team | S1 to S3, S3 also for OT engineers at the 3 plants | | Jurisdiction table | One country plus remote staff countries | Countries of the two offices and of any remote staff | Four countries, local counsel sign-off per country | | Contractors | Contractors screened directly as employees | Agency attestations, supplier flow-down | Supplier attestations, sample audits at supplier reviews | | Evidence for audit | Screening outcome list for all 46 people | Sample of joiners per quarter, pending list | Per-site screening dashboard, country variances recorded | *Example* level mapping for Quillmere Analytics Ltd: | Level | Employees | Contractors | Total | |---|---|---|---| | S1 Baseline | 20 | 6 | 26 | | S2 Enhanced | 12 | 2 | 14 | | S3 High trust | 6 | 0 | 6 | | Total | 38 | 8 | 46 | ## 13. Records and evidence | Record | Proves | Owner | Location | Retention | |---|---|---|---|---| | Screening outcome record per person | Checks done before access | HR | HR system, restricted area | Employment plus [period] | | Pending clearance list (7.3) | Higher access withheld until cleared | HR | HR system | [2] years | | Adverse finding decisions (section 8) | Fair individual assessment | HR, legal | HR system, restricted | Per legal register | | Jurisdiction table sign-offs (3.3) | Legal review per country | Legal counsel | Document management system | Life of the version plus [3] years | | Supplier screening attestations | Third-party personnel screened | Supplier manager | Supplier register DOC-ISMS-066 | Contract term plus [period] | | Onboarding tickets with clearance confirmation | No access before clearance | IT service desk | Ticketing system | [2] years | ## 14. Metrics | Metric | Target *(Example)* | |---|---| | Joiners with screening completed before access, at the required level | 100% | | Pending clearances older than 30 days | 0 | | Suppliers with access that have a current screening attestation | 100% | | S3 role holders re-screened or re-declared on schedule | 95% or more | ## 15. References | Reference | Edition | Use | |---|---|---| | ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html, Amd: https://www.iso.org/standard/88435.html | 2022, Amd 1 2024-02-23 | Control A.6.1, links to A.6.2 and A.5.19 | | ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html | 2022 | Guidance on screening | | NIST SP 800-53 Rev. 5 (release 5.2.0, August 2025), control PS-3 Personnel Screening and PS-7 External Personnel Security | Rev. 5 | Optional crosswalk | | Regulation (EU) 2016/679 (GDPR), Article 10 | 2016 | International example of criminal record limits | Related templates: `isms/confidentiality-nda`, `isms/security-disciplinary-process`, `isms/offboarding-security-checklist`, `ops/onboarding-checklist`, `isms/access-control-policy`, `isms/supplier-register`, `isms/supplier-security-agreement-27036`, `compliance/legal-register`, `compliance/gdpr-ropa`, `compliance/dpia`, `data/data-retention-deletion-standard`, `isms/control-evidence-matrix`. ## Standard and licence note Structure aligned with ISO/IEC 27001:2022 including Amd 1:2024, Annex A control A.6.1, with guidance in ISO/IEC 27002:2022. The screening levels, checks, process, examples and guidance are original wording; no ISO or IEC text is reproduced. ISO and IEC standards are copyrighted: obtain the official standard from ISO or your national standards body (https://www.iso.org/standard/82875.html). Check the current edition and amendments, and the current law in each country, before use. This is a documentation format, not legal advice. Template licence: MIT.