What A.6.1 screening asks for and why auditors sample it
A.6.1 requires background verification checks on candidates before they join and on an ongoing basis during employment, carried out within applicable laws and ethics and proportionate to the business requirements, the classification of the information the person will access, and the risks perceived for the role. If an audit is coming or a customer has asked for proof of background checks, the question to answer is not whether screening happens in principle but whether your organization can show, for each in-scope person, which checks were run, when, against which role requirements and by whom. The risk behind the control is insider exposure: a hire with access to customer data, production systems or payment flows who has a history the organization never looked at. Screening is one of the few preventive controls that acts before access is granted, which is why auditors treat it as a people control that sits next to A.6.2 Terms and conditions of employment and A.6.6 Confidentiality or non-disclosure agreements at onboarding.
The hard part is consistency and local law. What can be checked, such as criminal records, credit history, education or references, depends on the jurisdiction, and some checks need explicit consent or are restricted for certain roles. Records are also scattered: HR holds offer letters, a background check provider holds reports, a recruiter holds reference notes, and contractors may be screened by an agency whose files you never see. Before any audit, confirm with legal counsel which checks are permitted for each role family, write that rule set down, and decide which party retains each record. Ask any third-party screening provider what evidence they can release to you and how long they keep it. Also decide what happens to screening for internal transfers into sensitive roles and for contractors, since auditors often ask about both.
Auditors do not usually accept a single policy statement as proof. They sample a set of recent joiners and some people who changed role, then ask for the screening record for each, the role requirement it was matched against and the approval for any exception. Good evidence is short and traceable: a role-to-screening matrix, a dated check record per person with its result and approver, and a documented escalation path for adverse findings. The control also asks for checks during employment where your risk assessment calls for them, so define the trigger, such as a move into privileged access, and keep records of those too. Your certification body will confirm the exact sample and evidence they expect, so agree the evidence format with them before the audit rather than assembling it afterward.
Which roles, data and third parties fall inside A.6.1 scope
A.6.1 applies to anyone who will access the organization's information, but the depth and timing of checks change with the role and the data it touches. The cards below show the scoping decisions that change the screening work, so you can document which groups are in scope and why.
Employees by role risk tier
Scope starts by sorting employees into risk tiers based on the information and systems each role can reach. A standard role with access to internal documents usually needs a lighter check than a finance or customer data role. Record the tier logic in writing, because an auditor will ask why two employees received different checks. Confirm with your HR and legal teams which checks each tier may lawfully include before you set the matrix.
Contractors and temporary staff
Contractors often reach the same systems as employees but sit outside standard HR onboarding. Decide whether screening is performed by your organization or required from the contracting firm, and write that obligation into the contract. Auditors look for evidence that contractors were checked to the same tier as the employees they work alongside, so keep the records tied to each named individual.
Privileged and production access roles
Administrators, database owners and staff with production change rights carry the highest impact if they misuse access. These roles usually justify the deepest checks and the most frequent re-checks during employment, where local law allows. Map each privileged account in your identity system to a screened person so the link between access and screening can be sampled.
Developers with source or secrets access
Developers who can push code, read repository secrets or hold signing keys can insert changes that bypass other controls. Screening scope should cover anyone with write access to source repositories, build pipelines or secret stores, not only staff with production logins. Confirm how your repository permissions map to people, since shared or inherited access can hide who actually holds the capability.
Third-party personnel supplied by agencies
Staff placed through recruitment or managed service agencies may never be employed by you, yet they work inside your environment. Put verification duties in the agency contract, specify the checks and the information you need back, and reserve the right to refuse a placement. Ask for evidence of completion per individual rather than a general assurance from the agency.
Candidates in regulated jurisdictions
Some countries restrict which checks may be run on candidates, how long criminal record data may be kept, or whether consent must be obtained in a specific form. Identify the jurisdictions where your candidates live or work and get legal advice on permitted checks before setting the matrix. Where a check is not permitted, document the compensating step you took, since A.6.1 requires checks to stay within applicable law.
How an assessor tests A.6.1 and which findings they raise
This table lists the steps an assessor takes to test A.6.1 Screening, the evidence each step asks for, and the findings that appear most often when screening is weak. Read each row as a question the assessor will put to the organization, and use the evidence column to prepare records before the audit starts.
| Test step | Evidence requested | Common finding |
|---|---|---|
| Review the screening policy and its link to information classification | Approved screening policy, the classification scheme it references, and a mapping of which roles access which classes of information | Policy exists but does not name any classification level or role category |
| Sample new joiners and confirm the screening record was completed before the start date | Screening records dated before first system access, with the check type and result for a sample of recent hires | Checks completed after the start date, or no record kept for some joiners |
| Sample staff in privileged roles for periodic re-screening | Re-screening schedule or trigger rules, and completion records for privileged users selected from the access list | No re-screening defined for privileged or long-tenured staff |
| Check that agency and contractor contracts require equivalent checks | Contract clauses with staffing agencies and contractors, and evidence the supplier completed the checks for sampled individuals | Contracts silent on screening, or the organization cannot show checks for contractor staff |
| Check that legal limits on checks are documented | Written record of what each jurisdiction permits, the checks restricted by local law, and how the organization responds to refused consent | Checks run in a region where local rules were never reviewed, or no record of legal limits exists |
| Confirm one rule set maps roles to check depth | Role matrix showing which roles receive which checks and who approved the matrix | No defined rule for which roles get which checks, so decisions vary by hiring manager |
How to implement A.6.1 step by step
This sequence turns A.6.1 from a policy statement into a repeatable screening process, so each role gets checks proportionate to its access, every check is completed before access is granted, and an auditor can trace each hire to a recorded result.
Define role risk tiers against information classification
Start by listing the roles in scope and the information each one can reach, using the classification scheme already in your information security policy. Group roles into a small number of risk tiers, such as standard, elevated and privileged, and record which classification levels each tier touches. Human resources, the information security lead and the hiring managers for the highest-risk functions should sign off. The output is a tier matrix that maps each role to a tier, the checks that tier requires and the classification it accesses. The step is done when every job family has a tier and the matrix is approved and version controlled.
Document permitted checks per jurisdiction with legal review
For each tier, list the background checks you intend to run, such as identity verification, employment history, education, professional references or criminal record checks. Then confirm for each country where you hire which checks are lawful, what consent is required, and what data protection rules apply to the results. Legal counsel with employment and data protection experience should review the list before it is used. The output is a jurisdiction checklist that shows, for each location and tier, the permitted checks, consent steps and retention limits. The step is complete when counsel has signed off and the checklist is linked from the hiring procedure.
Set the screening sequence in the hiring workflow
Place the checks at a fixed point in the hiring workflow so they finish before a candidate receives system credentials, building access or access to sensitive data. Define which checks run after a conditional offer, which run before the start date and who triggers each one. Make the access provisioning step depend on a recorded clearance so that no account can be created without it. The output is a documented workflow diagram and a provisioning rule. The step is done when a test hire of each tier shows that access cannot be granted before the required checks are recorded as complete.
Assign an owner and a screening record system
Name one accountable owner for screening, usually from human resources, with a deputy for continuity. Choose where results are recorded, which may be the HR information system, a restricted case register or a controlled spreadsheet with access logging. Each record should show the candidate or employee reference, the tier, the checks completed, the dates, the provider used and the decision. Confirm who can view results and how long they are kept under the jurisdiction checklist. The output is a screening log and an owner assignment in the roles register. The step is done when a sample hire has a complete log entry that the owner can produce on request.
Define ongoing re-checks for high-risk roles
A.6.1 also covers checks during employment. For privileged and other high-risk roles, define which checks are repeated, at what trigger points and by what method. Triggers can include a promotion into a higher tier, a transfer to sensitive systems or a change in legal status, where local law permits it. Keep re-checks consistent with the consent and retention rules set in the jurisdiction checklist. The output is a re-check schedule attached to the tier matrix. The step is complete when the schedule names the roles, triggers and owner, and the first re-checks are logged in the screening record.
Set a process for handling adverse results
Decide in advance what happens when a check returns a material concern, such as a mismatched identity, an unverified qualification or a relevant record. Define who reviews the finding, how the candidate or employee is told and given a chance to respond where law requires it, who makes the final decision and how that decision is recorded. Link this process to the disciplinary and access review procedures so that decisions on existing staff are consistent. The output is a written adverse result procedure and a decision form. The step is done when the procedure has been tested on a hypothetical case, labeled as illustrative, and the outcome is recorded in the screening log.
Review the process and retain evidence for audit
Have the owner sample recent hires and role changes against the tier matrix, the jurisdiction checklist and the screening log, and record any gaps and corrective actions. Keep the approved documents, legal sign-offs, provisioning rule evidence and sample results in a controlled location so an auditor can test them. Confirm with your certification body which evidence it expects and how often it samples. The output is a review record with dated findings and actions. The step is complete when the first review has been closed out and the evidence pack is ready for an assessor.
Where screening evidence lives across HR, IT and vendors
Screening evidence for A.6.1 is rarely held in one place. The HR information system usually records the offer and start date, a background check provider holds the reports and consent forms, and the identity or access management system holds the account that the new hire is given. An auditor who samples a joiner will expect to follow a single thread from the screening decision to the access granted, so the organization must deliberately join these records. The organization owns the screening decision, the criteria applied to each role, and the retention of the records. A background check provider or implementation partner can help configure systems and export evidence, but neither issues the decision or passes judgment on the outcome for the organization.
The practical link is a shared identifier. Set a unique candidate or employee ID in the HR system, carry it into the provisioning ticket, and record the screening status (completed, outstanding or waived with approval) on that ticket before the account is created. Where the check was performed by a provider, store the provider's case reference alongside the ID, not only in the provider portal. For a sample of recent joiners, an auditor should be able to move from the ticket to the screening outcome and then to the role-based access granted, with dates in the right order. Illustrative example: a ticket that shows an account created two days before the check completed is a finding to explain, not to hide. Open-source identity and ticketing tools can hold these fields, but confirm with each vendor or project that custom fields, approval states and audit logs are supported, and that the retention period and deletion behavior match your legal obligations for background data.
Evidence that passes an A.6.1 sample
An auditor testing A.6.1 Screening starts with a sample of hires and roles, then works back to the policy that set the screening rules. Each card below is one artifact that connects those steps, and together they show that screening was defined, applied and kept current.
Screening policy with tiering
The written policy sets which roles get which checks, such as identity and right-to-work confirmation for all staff and extended checks for privileged administrators or staff handling regulated data. Auditors compare the tiers against the roles in the sample, so a tier must name the job families it covers. Review it quarterly with the compliance lead, and record each change with the approver and date so the version in force on a hire date is provable.
Jurisdiction checklist with legal sign-off
Background checks must stay within applicable law, so keep a per-country or per-state checklist of permitted checks, consent wording and retention limits. Legal counsel should sign off each entry and date the sign-off. An auditor will ask how a check was chosen for a candidate in a given location, so the checklist must match the checks actually run. Confirm it again whenever you hire in a new jurisdiction.
Completed screening records per hire
For each sampled hire, the auditor expects a record showing which checks were required, which were completed, the completion dates, and the outcome. Keep the consent form, the provider report or internal verification notes, and the approver's decision. Records should show screening finished before system access was granted. Spot-check a few recent hires each quarter to confirm every required field is filled in.
Link from screening to access provisioning
Screening only reduces risk if access waits for it. Show a workflow in which the identity or HR system holds the account until the screening status reads complete, and show the ticket or log entry that granted access. An auditor will pick a hire and compare the screening completion date with the first login or privilege grant. Test this path with a sample hire each quarter and keep the results.
Re-screening logs for high-risk roles
A.6.1 also covers checks during employment, so the policy should name the roles that are re-screened and the trigger, such as a periodic interval or a role change into a sensitive function. Keep a log of each re-screen with the date, the role, the result and any follow-up action. Confirm the log against the current staff list each quarter so transferred or promoted staff are not missed.
Contractor and agency contract clauses
Contractors and agency staff often reach systems without passing your HR screening, so their contracts or agency agreements must require equivalent checks and let you verify them. Keep the signed clauses, the agency's attestation of completed checks, and the list of contractors with system access. Review the agency list each quarter and confirm that each active contractor has a current attestation on file.
What meeting A.6.1 costs in money and effort
This table compares each cost component of running background screening under A.6.1, who is paid for it, whether it is one-time or recurring, what drives it up, and how to bring it down. Read it as a list of quote questions: most of the spend sits in provider fees and in keeping sampled records complete, while legal review and process build are mostly one-time.
| Cost component | One-time or recurring | What drives it | How to reduce it |
|---|---|---|---|
| Legal review of permitted checks per jurisdiction | One-time per jurisdiction, plus again on law change | Number of countries where candidates live or work, local limits on criminal record and credit checks, works council or data protection consultation rules | Limit checks to what each role needs, keep a jurisdiction matrix in one controlled document, and ask counsel to review only when laws change |
| Screening provider fees | Recurring, charged per check or per package | Check types chosen, number of hires and contractors, international checks that need local partners, and re-check frequency | Tier checks by role sensitivity, request a per-check quote with each package listed, and ask whether re-checks are priced separately |
| HR and IT process build | One-time, with occasional updates | Number of screening paths, integration with the applicant tracking system, consent capture, and decision rules for adverse results | Start with one documented workflow and add paths only where roles differ, and reuse existing onboarding tasks rather than building a new system |
| Ongoing sampling and record upkeep | Recurring, staff time each hire cycle | Volume of new joiners, how consent and check results are stored, and whether records link to the role and information classification | Store results as a dated record per person with a consent reference, and keep a single register so sampling takes minutes rather than days |
| Re-screening for privileged roles | Recurring, on a set interval or trigger | Number of privileged or financial roles, role change events, and local law limits on repeat checks | Re-screen only roles with elevated access and trigger checks on defined events such as promotion into those roles |
| External review of the screening policy | Optional, periodic | Whether the policy is written in-house, the sector's expectations, and whether an independent reviewer is needed for a customer or regulator | Ask for a fixed-scope review of one document, and confirm whether the reviewer will also support evidence sampling |
| Auditor sampling effort | Recurring, per audit cycle | Number of hires in the audit period, number of personnel with privileged access, and how quickly records can be produced | Keep records complete at the point of hire so the auditor's sample can be answered from one register rather than from several inboxes |
| Open-source tracking and evidence tooling | Recurring infrastructure cost, no per-seat license for self-hosted tools | Hosting capacity, administration time and backup needs, and whether the tool can produce audit-ready exports | Self-hosting a tracker in your own infrastructure can replace a per-seat compliance platform for this evidence, but confirm the tool's export and access logging features first |
Who owns screening, who can prepare it and what the auditor checks
Your organization owns A.6.1 in full. Screening is a people and legal decision, so the policy, the choice of checks for each role and the final hiring decision all sit with management, HR and the people who answer for the business. Legal counsel should confirm which checks are lawful in each jurisdiction where you hire, because the control itself requires screening to follow applicable laws, regulations and ethics.
- Policy and risk tiers: Approve a screening policy that states which roles get which checks, based on the classification of the information each role can reach.
- Legal sign-off: Have counsel confirm permitted checks, consent wording and retention periods for each country where you employ or contract staff.
- Hiring decisions: Decide whether a candidate proceeds. Record the decision and the reason, not only the check result.
- Records: Keep signed consents, check outcomes and dates in a restricted HR system, and confirm who can read them.
- Ongoing checks: Decide whether and when screening repeats during employment for sensitive roles, and document that decision.
Confirm that your records show the screening happened before the person accessed systems, since that order is what an auditor tests first.
An implementation partner can help you turn the screening decision into a repeatable design and an evidence trail. The partner does not decide who is hired, does not select or hold candidate data as the employer, and does not give legal advice on a jurisdiction unless it is qualified and engaged to do so. Its work is preparation: mapping roles to tiers, defining what records look like and assembling the sample pack an auditor will request.
- Role-to-tier mapping: Draft a matrix that links job families to the information classification they access and the screening tier that applies.
- Evidence trail design: Define where consent forms, provider reports and approval records are stored, and how they link to the person's access account.
- Sample pack preparation: Build a list of starters, leavers and role changers from HR and access systems so the auditor's sample can be pulled quickly.
- Tooling checks: Where an open-source or self-hosted HR or ticketing tool holds screening tasks, configure access controls and logs so the records are protected.
- Gap review: Compare what the records show against the policy and report the gaps to you for correction.
Ask any partner to put in writing which tasks it performs and which remain with your HR and legal teams.
The independent auditor, working through an accredited certification body where certification is sought, tests whether screening is designed and operating as your organization states. It samples records, compares them to the policy and interviews the people who run the process. It issues an audit finding, not an opinion on whether any individual is suitable for a role, and it does not perform the checks itself.
- Sampling: Expect the auditor to select a set of recent joiners, including contractors where they are in scope, and ask for screening evidence for each.
- Timing test: Confirm that checks were completed and approved before system access was granted.
- Policy alignment: Check that the tiers applied match the policy and the information classification for each role.
- Local law: Ask how you decided which checks were lawful in each jurisdiction, and look for the legal basis on file.
- Independence: The auditor cannot design your screening process as part of the same engagement without creating a conflict, so keep design work with your team or a separate partner.
Before the audit, confirm with the certification body how it will sample and which contractor records it expects to see.
Several parts of screening are commonly bought in from specialist providers, while accountability stays with your organization. Outsourcing a check does not transfer responsibility for the control, the lawfulness of the process or the records that prove it happened.
- Provider checks: Identity, employment history, education and criminal record checks are often run by background screening providers under contract.
- Legal review: Counsel or a specialist firm may review consent language and the permitted checks for each country where you hire.
- Contractor screening: Staffing agencies may screen their own personnel, so contract terms should require them to share evidence that the check was done.
- Records hosting: A provider may store reports, which should be covered by a data processing agreement and access limits.
- Scope: Ask providers for their check descriptions, consent steps and retention periods so you can confirm the records meet your policy.
Review each provider contract for the evidence it will return and when, because you will need it at audit time.
Where A.6.1 usually fails and how to close each gap
Screening under A.6.1 fails less often in the policy than in the details: which roles get which checks, when the checks run, and whether the records survive an audit. The cards below cover the gaps assessors most often find and the fix for each, starting with the link between screening depth and the information a role can reach.
Screening tier not tied to classification
Many organizations run one background check for every hire, regardless of what the role can reach. A.6.1 asks for checks proportionate to the classification of the information accessed and the perceived risks. Build a short tier table that maps each information classification level and privileged access type to a defined set of checks, then have HR and the information owner sign it. An auditor will compare a sample of roles against that table.
Checks completed after the start date
Offers are often released and accounts provisioned before the background check returns. Screening is meant to happen before a candidate joins, so a new hire may hold access to systems while the check is still open. Make the check a gating step in the onboarding workflow, so the access request cannot be approved until the screening status reads complete. Record the date of each result next to the account creation date.
Contractors excluded without clauses
Contractors, temporary staff and agency workers often bypass HR screening because they are not on the payroll. A.6.1 applies to people who access information, so the screening duty has to reach them through the contract or agency agreement. Write the required checks into the statement of work or supplier terms, and require the provider to confirm completion for each named individual before access is granted.
No re-screening for privileged staff
A.6.1 covers checks on an ongoing basis, yet most programs stop at hiring. Staff who move into administrator roles, handle payment data or gain access to sensitive datasets carry a different risk than they did at onboarding. Define triggers for re-screening, such as a role change into privileged access or a periodic review for high-tier roles, and log each re-check against the employee record.
Legal limits left undocumented
Screening must stay within applicable law, and the permitted checks differ by country, by state and by role. When the legal basis lives only in an HR manager's memory, an assessor cannot confirm that checks were lawful or consistent. Ask counsel to document, for each jurisdiction where you hire, which checks are allowed, what consent is required and how long results may be kept, and link that memo to the screening procedure.
Screening records in personal inboxes
Results are often emailed to a hiring manager and then forgotten, which leaves no retrievable evidence for a sampling audit. Keep screening outcomes in a restricted HR system or a controlled register with access logging, and store only the result and the date, not the full report, where local law requires it. Confirm that the record can be produced for any sampled employee within a short, agreed time.
Questions buyers ask about A.6.1 screening
How much effort does meeting A.6.1 screening take?
The effort depends less on the control text than on how many roles you hire into, how varied those roles are, and how many countries your staff sit in. A.6.1 asks for background verification before people join and during employment, scaled to the role, the information they will access, the perceived risks and applicable law. The work splits into a one-time design phase (defining check levels per role family, writing the procedure, agreeing which checks apply where) and a recurring phase (running checks for each hire, recording outcomes, and re-screening where the procedure requires it). Ask any provider to break its quote into design, tooling and recurring operation so you can see which part scales with hiring volume.
Can a small team run A.6.1 screening in-house?
Usually yes, if the team keeps the scope narrow and the process written down. A small organization can often tier its roles into a few groups, such as standard, elevated access and privileged administration, and apply a fixed set of checks to each group. The risks come from informal habits: checks run for some hires but not others, outcomes stored in email, or no record of who approved an exception. A simple checklist in a shared, access-controlled system, with a named owner and a monthly review, is often enough to produce the records an assessor samples. Confirm with your certification body how it expects a small organization to show consistency.
How long before an audit must screening already be running?
Screening must be operating for long enough that an assessor can sample real hires against the procedure. An assessor cannot test a process that has never run, and a procedure written the week before an audit usually leaves no records to inspect. The practical question is how many people have joined since the procedure took effect, and whether those joiners went through the defined checks at the right level. Plan backwards from your audit date, count the hires expected in that window, and confirm with your auditor how many samples it will take. Hires who joined before the procedure can be handled as a documented gap with a decision on re-screening.
Can a partner prepare the evidence for A.6.1?
A partner can prepare the systems, procedures and evidence trail, but the organization keeps ownership of the control and of the decisions about who is screened and how. DeployOpen plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure, so it can help set up a recruitment or HR workflow that records check levels, approvals, dates and exceptions in a system the client controls. It does not issue audit reports or certificates, and it does not carry out background checks itself. Agree the handover in writing: which records the platform produces, who reviews them, and which checks are performed by a licensed screening provider.
What does A.6.1 need from HR and legal?
HR and legal own the rules that the technical side cannot decide. HR typically defines which roles need which checks, obtains candidate consent, and records outcomes. Legal confirms which checks are lawful in each jurisdiction, what data may be collected and retained, how candidates are told about the process, and how adverse results are handled. A.6.1 explicitly ties screening to applicable laws, regulations and ethics, so these sign-offs form part of the evidence. Ask legal to document its position per country and to review the procedure at least when the law changes or a new hiring location is added.
Are background checks required in every country?
No standard requires the same background check everywhere, and A.6.1 does not mandate specific checks. The control asks you to screen within applicable law, so the permitted checks depend on where the person is hired and where the role is performed. Some jurisdictions restrict criminal record checks, limit the use of credit history, or require the candidate's consent in a specific form, while others allow broader checks for sensitive roles. Build a country matrix showing which checks are used, which are excluded and why, and what approval each needs. Confirm the matrix with local counsel before relying on it.
