ISO 27001 Background Screening: Complete 2026 Guide

ISO 27001 background screening is one of the cheapest controls in Annex A to put in place and one of the easiest to fail an audit on, because the thing that limits you is rarely security — it is employment and privacy law.

Annex A 6.1 asks for verification checks that are proportional to risk and carried out “taking into consideration applicable laws, regulations and ethics”. That last clause does more work than most people notice. A screening standard that sails through a US audit can have no lawful route in parts of the EU, and a policy written to the strictest jurisdiction will stall hiring everywhere else.

This guide covers what ISO 27001 background screening actually requires, what it never says, where the legal limits sit in the EU, UK and US, how to set proportionate tiers, and the records an auditor actually asks to see.

What ISO 27001 background screening requires under Annex A 6.1

ISO/IEC 27001:2022 carries 93 Annex A controls in four themes — 37 organizational, 8 people, 14 physical and 34 technological. ISO 27001 background screening is A.6.1, the first of the eight people controls, and the only one that fires before someone is inside the organization at all.

The control requires background verification checks on candidates for employment, carried out before they join and on an ongoing basis afterwards, taking into account applicable laws, regulations and ethics, and proportional to the business requirements, the classification of the information to be accessed, and the perceived risks.

Three structural facts shape everything else:

• It is not new in 2022. A.6.1 maps from ISO/IEC 27001:2013 control A.7.1.1, also called Screening. A gap assessment built on the 2013 control set still catches it, unlike genuinely new 2022 controls such as A.8.11 data masking.
• It is not a mandatory document. Mandatory documented information comes from the clauses, not from Annex A. The Statement of Applicability is mandatory under clause 6.1.3; a screening procedure is not. Smaller organizations can carry the detail in the SoA entry, and most organizations past about fifty staff end up writing a standard anyway because consistency is what gets sampled.
• It specifies no method. The standard sets no re-screening interval, no list of required check types, no retention period for screening records, and no requirement to use a third-party provider. ISO/IEC 27002 offers guidance on all of that, but guidance is not an auditable requirement on its own.

That last point is the one to internalise. Almost every number you will be tempted to put in an ISO 27001 background screening policy — annual re-checks, seven years of employment history, two references — is convention, not requirement. Write it anyway, but know that you are the one who has to justify it.

Three things most ISO 27001 background screening policies get wrong

“On an ongoing basis” is in the control text

Most ISO 27001 background screening policies describe a pre-hire process and stop at the offer letter. That is a gap against the wording of the control itself, which reaches past joining. Ongoing does not mean annual — the standard gives no interval — but it does mean you have to define a trigger and justify it from risk.

The pattern that holds up in an audit is event-driven plus a cycle for the top tier: re-verify when someone is promoted into a privileged role, when their access classification ceiling rises, or when the role moves into the scope of a regulated activity, and run a defined periodic re-check for administrators and anyone who can bypass a control.

It reaches contractors and agency staff, not just payroll

The control’s population is candidates for employment, but an ISMS scope almost never stops at payroll. Where a contractor gets the same access as an employee, the same standard of assurance has to apply — either you screen them directly or you transfer the obligation contractually and keep the right to see evidence. This is where A.6.1 meets the supplier controls in A.5.19 to A.5.21.

In organizations with a genuinely tight employee process, this is the single most common ISO 27001 background screening finding: HR screens every permanent hire properly, and an agency developer with production access walks in with nothing on file.

Proportionality is a decision you have to evidence

“Proportional to the classification of the information to be accessed” ties screening directly to your classification scheme under A.5.12. If the classification register does not exist, or exists but is not applied, proportionality cannot be evidenced — the auditor has no baseline against which to test your tiers, and the tiers become assertion rather than control.

Fix the classification side first. A three-tier ISO 27001 background screening model built on a classification scheme nobody uses is a documented control with nothing underneath it.

The legal constraint on ISO 27001 background screening across the EU, UK and US

This is the part that separates an ISO 27001 background screening policy that passes legal review from one that does not. The same check is mandatory in one jurisdiction, optional in another and effectively unavailable in a third.

Jurisdiction	What constrains the check	Practical effect
EU / EEA	GDPR Article 10: data on criminal convictions and offences may be processed only under the control of official authority, or where Union or Member State law authorises it with appropriate safeguards. A comprehensive register of convictions may be kept only under official authority.	A blanket criminal-record check on every hire usually has no lawful route. National law decides which roles qualify, so the answer differs by country even inside the EU.
United Kingdom	The Disclosure and Barring Service operates four levels: Basic, Standard, Enhanced, and Enhanced with Barred List(s). Basic carries no role restriction; Standard and Enhanced are limited to roles made eligible by statute.	You cannot buy a higher level because a role feels sensitive. Eligibility is set in law, and Standard and Enhanced applications go through a Registered Body rather than the candidate.
United States (federal)	The Fair Credit Reporting Act requires a standalone written disclosure and the candidate’s authorization before a consumer report is obtained, then a pre-adverse-action notice enclosing a copy of the report and the CFPB summary of rights, then a final adverse action notice.	Litigation here is driven by process defects, not by check results. The disclosure has to stand on its own as a document — bundling it with waivers or other policies is the classic error.
United States (state and local)	Fair-chance or “ban the box” laws. Around fifteen states clearly reach private employers on the National Employment Law Project’s list, with some trackers counting up to seventeen, alongside more than 150 city and county ordinances.	Timing is the variable. In covered jurisdictions the criminal-history question often cannot be asked until after a conditional offer, and local rules can be stricter than the state’s.

So the deliverable is not one global ISO 27001 background screening standard. It is one global standard of assurance with per-jurisdiction methods. Write the policy as outcomes — identity confirmed, right to work confirmed, employment history confirmed across a stated period, claimed qualifications verified, criminal-record check performed where lawful and the role is eligible — and keep a jurisdiction annex that records how each outcome is achieved locally and who confirmed that it is lawful.

Auditors accept that structure readily, because it evidences the “applicable laws” clause directly. It is also the only version that survives contact with a works council or an employment lawyer.

One technical point worth getting right in your privacy records: criminal-offence data sits under GDPR Article 10, not under the Article 9 special categories. It is handled with comparable care but it follows its own rule, and mislabelling it in a DPIA or a record of processing is a cheap mistake to avoid.

Setting proportionate ISO 27001 background screening tiers

Set ISO 27001 background screening depth by the access a role can reach, not by job title. Titles churn and vary between teams; access classification does not.

Tier	Who it covers	Typical checks	Re-verification trigger
Tier 1 — Standard	All hires with access to internal information	Identity and right to work, employment history with gaps explained, references	None beyond hire
Tier 2 — Elevated	Access to confidential information, customer data, or finance systems	Tier 1, plus verification of claimed qualifications, a basic criminal-record check where lawful, and sanctions or adverse-media screening where the role justifies it	On promotion into the tier
Tier 3 — Privileged	Administrators, the security team, developers with production access, anyone able to bypass a control	Tier 2, plus an enhanced check where the role is legally eligible, a credit check where financial authority justifies it, and documented management sign-off	On entering the tier, plus a defined periodic cycle

Then write the ISO 27001 background screening exception path, because you will need it within the first month. A candidate will come from a jurisdiction where a check is unavailable, or an employment history will have a gap nobody can document a decade later. The standard gives you no answer here; your policy has to. Realistic options are delaying privileged access until a probation period closes, adding supervision or additional logging, capping the classification ceiling the role can reach, or withdrawing the offer where nothing compensates for the gap. Record the decision and the name of the person who made it — that record is the control.

Access tiers are also where ISO 27001 background screening connects to the rest of the ISMS. The same tier that drives the depth of the check should drive the access review cycle in your ISO 27001 access control policy, and it should drive the thoroughness of ISO 27001 offboarding at the other end of the employment lifecycle. Screening and offboarding are the same control problem viewed from opposite ends, and auditors increasingly sample them as a pair.

The evidence an auditor asks for on ISO 27001 background screening

ISO 27001 background screening is sampled, not inspected. The auditor takes your starter list for the last twelve months, picks names across tiers, and asks for the record behind each one. A strong policy with no per-hire records is still a finding.

Record	Why it exists	Where it usually lives
SoA entry for 6.1, marked applicable with a justification	Clause 6.1.3 requires justification for inclusion and exclusion of each control	Statement of Applicability
The screening standard itself	Shows proportionality was decided deliberately rather than improvised per hire	ISMS document set or HR policy library
Jurisdiction annex or legal-basis note	Evidences the “taking into consideration applicable laws” clause	Policy annex, privacy records
Per-hire screening record — what was checked, when, by whom, with what outcome	This is what gets sampled	HR system or applicant tracking system
Exception and sign-off records	Shows the exception path is real and used, not decorative	HR system
Contract clauses transferring the standard to agencies and suppliers	Links A.6.1 to the supplier controls and closes the contractor gap	Contract register

Retention deserves its own line in the policy. ISO 27001 background screening records are personal data, and in the EU they can touch Article 10 data, so an indefinite archive of full background reports is a privacy finding waiting to be written. The defensible pattern is to retain the outcome, the date, the tier and the verifier, and to dispose of the underlying report once the decision is made and any appeal window has closed.

Mark the control applicable in your ISO 27001 Statement of Applicability before the audit, not during it. A.6.1 is almost never legitimately excluded — if you hire anyone at all, the control applies, and an exclusion here attracts far more attention than it saves.

How ISO 27001 background screening maps to other frameworks

Framework	Reference	What it requires
ISO/IEC 27001:2013	A.7.1.1 Screening	The direct predecessor, carried over into A.6.1 in the 2022 edition. This is not a new-in-2022 control.
NIST CSF 2.0	GV.RR-04	“Cybersecurity is included in human resources practices.” The implementation examples cover personnel screening, onboarding, change notification and offboarding. It maps from CSF 1.1 subcategory PR.IP-11. CSF 2.0 carries no certification.
SOC 2	CC1.4 (COSO Principle 4)	Commitment to attract, develop and retain competent individuals; considering the background of individuals is one of the points of focus. Points of focus are not individually mandatory, and SOC 2 is an attestation rather than a certification.
GDPR	Articles 10 and 5(1)(c)	The criminal-offence data rule, plus data minimisation — which is what makes an over-broad check a privacy problem as well as a legal one.

If you are running ISO 27001 alongside the NIST Cybersecurity Framework, GV.RR-04 is wider than A.6.1 — it reaches onboarding, access change notification and offboarding too. Build the HR security process once, map it to both, and you will not be asked the same questions twice.

Closing the A.6.1 gap in 30 days

1. Days 1 to 3. List every role inside ISMS scope and the highest information classification each one can reach. Assign tiers from that, not from job titles.
2. Days 4 to 7. Establish what is lawful in each hiring jurisdiction. Get one written answer per country from counsel or a competent provider, and file it as evidence.
3. Days 8 to 14. Write the ISO 27001 background screening standard as outcomes plus a jurisdiction annex. Include the exception path and name the sign-off authority.
4. Days 15 to 21. Fix the contract side — agency and supplier clauses that transfer the standard, with an explicit right to evidence it.
5. Days 22 to 26. Build the per-hire record: one row per starter with tier, checks completed, date, verifier, outcome and exceptions. Backfill the last twelve months where you can, and record honestly where you cannot.
6. Days 27 to 30. Update the SoA entry for 6.1 and the retention schedule, then brief hiring managers. They are the people the auditor will put the questions to.

Brief the managers properly rather than circulating the policy. The same applies to the awareness obligations next door in A.6.3 — see ISO 27001 security awareness training for how clause 7.2, clause 7.3 and A.6.3 split across three different populations. For the full control set and where A.6.1 sits within it, start from our guide to the 93 ISO 27001:2022 Annex A controls.

ISO 27001 background screening FAQ

Does ISO 27001 require criminal background checks?

No. ISO 27001 background screening never names a single check type. The control requires verification that is proportional to risk and lawful where you operate. A criminal-record check is one available method, usable only where the law permits it and the role is eligible — and in much of the EU, a blanket check on every hire has no lawful basis at all.

Is a screening procedure a mandatory ISO 27001 document?

No. ISO 27001 background screening is an Annex A control, and mandatory documented information is set by the clauses rather than by Annex A. The Statement of Applicability is mandatory under clause 6.1.3; a separate screening procedure is not. Small organizations can carry the method inside the SoA entry. Past a certain headcount a written standard becomes the only practical way to evidence that screening is consistent, which is what the auditor is really testing.

How often do you have to re-screen existing staff?

ISO 27001 background screening has no fixed interval in the standard. The phrase “on an ongoing basis” obliges you to define a trigger and justify it; it does not prescribe one. Event-driven re-verification on tier change, plus a defined cycle for privileged roles, is the common and defensible pattern. Annual is a convention — do not write it into a policy as though the standard required it.

Do contractors and agency staff need the same screening?

Where their access is equivalent, yes. Either you screen them directly or you transfer the obligation to the agency in contract and retain the right to see evidence. Equivalent access with no equivalent assurance is the most frequently raised A.6.1 finding in organizations whose employee process is otherwise sound.

What happens if a candidate’s screening comes back incomplete?

Decide in advance, because the standard will not decide for you. The workable options are delaying privileged access until probation closes, adding supervision or additional logging, capping the classification ceiling the role can reach, or withdrawing the offer where nothing compensates. Whichever you choose, record the decision, the compensating measures and the approver.

Does ISO 27001 background screening apply to staff hired before certification?

It reaches them through the proportionality test and the ongoing-basis wording rather than through a retrospective sweep. Someone moving into a privileged role is being granted access their original check never covered, so that move is the natural trigger. Most organizations screen at the point of tier change and document that decision, rather than re-screening the entire existing population at once.

If you are building ISO 27001 background screening from nothing, the screening standard, the per-hire screening record and the SoA entry that justifies A.6.1 are three of the documents in the ISO 27001 Toolkit — 165 editable templates covering all 93 Annex A controls plus the mandatory clause documentation, $99 one-time with no subscription. It is the fastest way to get a defensible screening standard, a jurisdiction annex and a sampling-ready record in front of an auditor.