ISO 27001 Annex A 6.1: screening that gates access before day one

The new starter's laptop is on its way, their Okta account is ready to create, and the background check hasn't come back. That gap is where ISO 27001 Annex A 6.1 fails audits, and the paperwork is rarely the problem.

This guide is for information security managers, compliance heads and HR leads at regulated UK firms of 25–250 staff. It covers what ISO 27001 screening requires, how to tier checks proportionately under UK GDPR, how to block provisioning until clearance lands, and what auditors test.

What does ISO 27001 Annex A 6.1 require?

ISO 27001 Annex A 6.1 requires you to check that anyone who will touch your systems or client data is who they claim to be and suitable for the role, before they start. Depth scales with the risk of the seat, and the control is preventive: it keeps unsuitable hires away from information.

The control covers everyone doing work for you: permanent staff, part-timers, temps and people supplied through an agency or vendor. For supplier-provided staff, the vetting obligation travels through the contract rather than through your HR file.

It protects confidentiality, integrity and availability alike, since an untrustworthy insider can leak, corrupt or sabotage with equal ease. It sits in the people controls of Annex A, which cover the staff lifecycle from hire to exit.

Three neighbouring controls shape how an auditor reads it:

• Annex A 6.2, terms and conditions of employment turns a cleared candidate into a bound employee through contract terms.
• Annex A 5.20, supplier agreements is how screening for supplier-provided staff gets enforced.
• Annex A 5.18, access rights is where auditors check that nobody received access before their checks cleared.

The business case is plain. Inflated titles, invented degrees and unexplained gaps turn up routinely once someone looks. In a 25–250-person firm, one fraudulent hire in an engineering or finance seat can reach most of what matters within a week of starting. Vetting is also a standing question on enterprise security questionnaires, and for FCA-regulated firms it feeds fitness-and-propriety expectations. Most of this is good hiring practice you already want. The control asks you to make the depth deliberate and provable.

How do you build a proportionate tiered screening matrix?

Build a two-tier matrix. Baseline for everyone: photo-ID identity check, right-to-work confirmation, three to five years of employment history with gaps queried, and references actually followed up. Add an enhanced tier for privileged IT, finance and executive seats, justified by the role's risk. Verify qualifications only where they are why you're hiring.

The enhanced tier typically means a criminal record check (DBS in England and Wales, Disclosure Scotland or AccessNI elsewhere) and, where lawful and justified, a credit or directorship check. Each of those needs a stated justification, which the next section covers. Write the whole matrix down with a named approver, because an auditor's early question is who decided which roles get deeper checks.

Each baseline check catches a specific failure:

• Photo-ID identity check catches impersonation and false identities.
• Right-to-work confirmation catches an employment that would be unlawful before it starts.
• Employment history catches inflated titles and unexplained gaps, provided someone queries the gaps.
• Followed-up references catch what the CV leaves out. A reference that is filed but never read catches nothing.
• Qualification verification with the issuing body catches invented degrees, so spend it where the qualification is the reason for the hire.

The usual failure is a single depth for everyone.

A process that checks the receptionist exactly as it checks the database administrator protects neither seat.

How far does UK GDPR let you go with criminal and credit checks?

Only as far as the role's risk justifies. ICO guidance says vetting must be proportionate to an identified risk and a targeted way of achieving your objective, so blanket criminal or credit checks on every hire are disproportionate. Tie each enhanced check to a named risk, tell candidates what you check, and capture consent.

The ICO guidance on pre-employment candidate vetting is the reference point under UK GDPR and the Data Protection Act 2018. Its test applies to each check separately: what risk does this address, and would a lighter step address it? The only exception is a legal duty to vet everyone. The guidance applies the same rule to credit reference checks: never routine, and always justified by the role.

Seats that usually clear the bar are those with privileged system access, control of money or executive authority. A junior seat without those powers usually does not.

Before ordering any enhanced check, record four things:

1. The named risk: the specific harm this seat could do, such as releasing payments or administering production.
2. Why a lighter check would not do: the proportionality reasoning, in a sentence.
3. What the candidate was told: your privacy notice should list the checks performed.
4. Consent: captured before the check runs and kept on file.

Criminal record checks involve criminal offence data, which UK data protection law treats more strictly than ordinary personal data. ICO guidance says vetting with it will be high risk in most cases, which means a data protection impact assessment before the first check runs. Ask your data protection lead to confirm the lawful basis and the Schedule 1 condition you rely on.

One written rationale per enhanced seat also answers the auditor's question of who made the call and why. The same rationale holds up if a candidate or a regulator asks.

Do contractors, temps and agency staff fall under Annex A 6.1?

Yes. NPSA guidance says a suitable level of screening applies to everyone given access to organisational assets, including permanent, temporary and contract workers. Under Annex A 6.1 the obligation travels through supplier and agency contracts: require equivalent vetting in the contract, then ask for confirmation you can show an auditor.

The NPSA guidance on employment screening ties screening to access to assets rather than to the type of contract. A contractor with a production login carries the same insider risk as a permanent engineer with one, and an auditor will treat them alike.

Supplier-provided staff are not in your HR system, so the obligation has to be built into the paperwork. Three clauses do the work:

• A vetting standard: checks matching your tier for the seat the worker will fill.
• Written confirmation: the supplier confirms completion before placement, in a form you can file.
• Notification: the supplier tells you if a check fails, lapses or is still pending.

The confirmation is the evidence. Without it the clause is only a promise, and auditors who ask for a contractor's file in the sample expect to see both. Freelancers you engage directly have no supplier to vet them, so the baseline checks run through you like any other hire.

The pitfall is the silent contract. Agency workers get accounts, the contract says nothing about vetting, and nobody asked the supplier. Review current agency and freelancer agreements for the missing clause, ask for confirmation for people already on site, and add the clause at the next renewal. Contractor accounts then pass through the same clearance gate as employees.

What if screening results arrive after the start date?

Decide the fallback before it happens. Pre-agree one of four options: move the start date, onboard with restricted access, hold equipment back, or keep the offer conditional. Then record which option you took for each hire. What fails audits is improvising the decision each time.

Recording the choice is what turns a late result into an auditable decision. When an auditor asks what happened the last time a check hadn't returned by someone's start date, the answer should be a ticket, not a recollection.

Each option fits a different situation:

• Move the start date: cleanest for seats that need privileged access from day one.
• Onboard with restricted access: induction, training and non-sensitive tools only, with no client data or production.
• Hold equipment back: the laptop stays with IT until clearance lands.
• Keep the offer conditional: the contract states that employment depends on satisfactory screening.

We suggest pairing option to tier. Baseline seats can usually onboard with restricted access, while enhanced seats wait for clearance or start later.

Record three facts per hire: the option chosen, who approved it and the date. Put them in the onboarding ticket so the record is created as the decision is made. Day-one pressure then has somewhere to go that isn't a bypass.

Without a pre-agreed fallback, every late result becomes a negotiation between a hiring manager who wants a start and an HR lead who wants a clean file. The next section makes the chosen option technically binding.

How do you stop accounts being created before HR clears a hire?

Make clearance a provisioning precondition. The HR platform holds a screening-status field, and the joiner automation refuses to create identity-provider accounts until it reads cleared. Access before clearance then becomes impossible rather than merely forbidden, and each account's timestamps prove the order.

NCSC applies the same logic when you assess a cloud provider: the NCSC Cloud Security Principle 6 on personnel security asks for confidence in the trustworthiness of provider staff who can reach your data, together with technical measures that audit and constrain what they do. Hold your own joiners to the same standard: a screening status that nothing enforces covers only the first half.

Build the gate in five steps:

1. Add a screening-status field to the HR platform, with values such as pending, cleared and failed. Only HR can change it.
2. Connect the vetting provider so checks are ordered and results return through its API into the onboarding workflow, with no email chasing.
3. Make the joiner automation read the field. Accounts in Okta or Google Workspace are created only when the status reads cleared, and SaaS permissions follow from the identity provider.
4. Check the same field before equipment ships, so hardware leaves IT only for a cleared hire or a recorded fallback.
5. Route exceptions through the documented fallback from the last section, logged in the same workflow.

When the provider's result arrives and HR confirms it, the status flips and account creation can start without anyone noticing an email. The hire's first day is no longer waiting on a person to remember.

Remove the manual route as well. If administrators can still create accounts by hand, the gate is advisory, so restrict account-creation rights to the automation and a small named group, and log their use.

The workflow record is the evidence. Checks ordered, results received, clearance granted, account created: each step carries a timestamp, and nobody assembles the trail afterwards. A paper checklist records intent, while a gate changes what is possible.

Screening that finishes after the laptop ships isn't screening.

The pitfall this prevents is the quiet one. Accounts and laptops issued on day one while checks are in flight are convenience defeating the control, and nobody decides to do it. It happens because creating the account is the default and waiting is the exception. Inverting that default is the whole design.

How often should privileged and sensitive roles be re-screened?

For most roles, one check at hire is enough. For a small critical set, such as privileged engineers and finance signatories, repeat checks periodically at a proportionate cadence. Annual DBS renewal for a privileged engineer is defensible; re-vetting the whole company is theatre. Track renewals as recurring tasks with owners.

Mark re-screening in the matrix itself. Each enhanced-tier role carries a renewal interval, and the HR platform creates a recurring task with an owner and due date when the hire clears. Reminders go to the owner ahead of the date, and overdue items surface on a dashboard before an auditor finds them.

Re-checks face the same test as the first: proportionate to the role's risk, disclosed in the candidate privacy notice, with consent captured. Tell people at hire that periodic checks apply to their seat, so renewal doesn't arrive as a surprise.

People move, too. An engineer promoted into a privileged role enters the re-screening set on the day of the change, and the matrix should say which checks run at that point. At this scale the cadence covers a short list of seats, which satisfies auditors and enterprise customers without turning HR into a permanent vetting department.

How do auditors test Annex A 6.1 screening against provisioning timestamps?

Auditors take a joiner list from HR, pick two or three names, and cross-reference screening completion dates against account-creation timestamps from your identity platform. Contractors and internal referrals are favourites, because that's where firms quietly skip the process. Access routinely granted before checks complete is the failure they hunt for.

Expect questions like these in the room:

• "Show me the screening files for these three recent joiners, and make one of them a contractor."
• "This engineer started in June. Show me the checks were complete before their accounts were created."
• "What happened the last time a check hadn't come back by someone's start date?"
• "What do candidates get told about these checks, and where is the consent?"

The gate answers the timestamp question directly. Export the joiner list with the clearance date and the account-creation date side by side, and every row should show clearance first. For contractors, the file holds the contract clause and the supplier's confirmation.

Internal referrals, founder acquaintances and C-level hires are the population auditors target, because they are the ones most likely to skip standard onboarding. Route them through the same gate and the same status field, and the exemption disappears.

"We know them" is not a screening result.

Informal checking fails too: the work may well have happened, but without records it fails the audit anyway. Certification-body practice grades the extremes clearly. No vetting process at all, or access routinely granted before checks complete, is the absence-or-breakdown case and grades major. A single unreturned reference, one undocumented late-results decision or a stale matrix grades minor, though a pattern of minors can add up to a major.

With the gate in place, the audit trail is a by-product of onboarding, not a scramble the week before the visit.

Frequently asked questions