NIS2 personnel security: which staff to screen and how

Why personnel security is part of NIS2

NIS2 treats people as part of your attack surface. One administrator with production access can do more harm than most outside attackers ever get the chance to. That is why Article 21(2)(i) of the NIS2 Directive lists human resources security next to access control and asset management as a required risk-management measure.

For many tech companies, Commission Implementing Regulation (EU) 2024/2690 turns that one line into concrete duties. Annex point 10.2 requires you to decide which roles need a background check and to finish that check before anyone starts in the role.

This guide is for HR, security and compliance leads at EU tech companies in the scope of NIS2. It covers which staff to screen, what the regulation actually says, when to rescreen and what evidence an auditor will ask for.

What the law requires: Article 21 and Annex point 10.2

The Directive sets the principle; the Implementing Regulation sets the detail. Regulation 2024/2690 applies directly to eleven types of digital provider: DNS service providers, TLD name registries, cloud computing providers, data centre providers, content delivery networks, managed service providers (MSPs), managed security service providers (MSSPs), online marketplaces, online search engines, social networking platforms and trust service providers. If your company is one of these, the Annex is binding on you in every EU country.

If you are in scope of NIS2 but not on that list, your national law sets the detail. Even then, the Annex is the most concrete EU text on personnel security, and supervisors and auditors use it as a benchmark.

Here is what point 10.2 says, in plain English:

• Point 10.2.1 requires you to verify the background of employees, and where applicable of direct suppliers and service providers, to the extent feasible, if their role, responsibilities and authorizations require it. In practice, screening is risk-based rather than universal, and it reaches contractors.
• Point 10.2.2(a) requires criteria for which roles, responsibilities and authorities may only be held by someone whose background has been verified. In practice, you need a written role matrix.
• Point 10.2.2(b) requires the verification to be complete before the person starts in that role. It must follow applicable law and ethics and be proportionate to business needs, asset classification, the systems accessed and perceived risk. In practice: no access before the check is done, and the depth of the check follows the risk.
• Point 10.2.3 requires you to review the policy at planned intervals and update it where necessary. In practice, put a review date on the policy and keep toit.

Three neighboring points matter too. Point 10.1.2(d) asks for hiring mechanisms such as reference checks, vetting, validation of certifications or written tests. Point 10.1.3 requires you to review role assignments at least once a year. Point 5.1.4(c) requires supplier contracts to include background verification requirements for the supplier's staff, where appropriate.

The recitals of the Regulation give examples of what verification may include: checks of a person's criminal record or past professional duties, as appropriate for the role. Nothing in the text requires a criminal record check for everyone.

Which roles to screen

Screen every role that can change, bypass or read past your security controls. The Regulation leaves the criteria to you, but it ties them to two things you should already have: your asset classification (point 12.1) and your access rights register (point 11.2). A role that touches your highest-classified assets or holds privileged access belongs in a screened tier.

Four questions sort most roles quickly:

1. Does the role hold privileged or administrative access to production systems, cloud consoles or identity providers?
2. Can the role read or export customer data at scale?
3. Can the role change code, configuration or security tooling that runs in production?
4. Does the role carry authority over security decisions, risk acceptance or large payments?

A yes to any question means the role needs a defined screening package. The tiers below are a starting point for a typical software or cloud company. Adjust them to your own systems.

• Tier 1: privileged access. Cloud and system administrators, SRE and DevOps engineers with production access, IAM administrators, DBAs, security engineers and SOC analysts. These roles can disable controls or reach all data. Suggested checks: identity, right to work, employment history, education and certifications, references, and a criminal record certificate where national law allows.
• Tier 2: sensitive access. Developers with merge rights to production, support engineers who see customer data, data engineers and incident responders. These roles can alter the product or see personal data. Suggested checks: identity, right to work, employment history, certifications and references, plus a criminal record certificate where lawful and justified.
• Tier 3: management body and key decision makers. Board members, CEO, CTO, CFO and CISO. Article 20 makes them accountable, and they accept risk on the company's behalf. Suggested checks: identity, employment history, directorship and insolvency checks, adverse media, and a criminal record certificate where lawful.
• Tier 4: general staff. Sales, marketing, finance and operations staff without privileged access. Standard hiring hygiene under point 10.1.2(d) applies. Suggested checks: identity, right to work and references.
• Suppliers and freelancers. Contract developers and MSP or offshore staff with access to your systems, covered by points 10.2.1 and 5.1.4(c). Apply the same package as the tier of the role they fill, either through a contract clause or by screening them yourself.

Write the result down as a role matrix and get it approved by management. That document is your evidence for point 10.2.2(a).

How to screen lawfully

NIS2 tells you to screen; the GDPR and national employment law tell you how far you may go. Point 10.2.2(b) builds this in: the check must respect applicable laws, regulations and ethics. A check that breaks privacy law will not count as compliance.

The main legal limits:

• Criminal records. Under Article 10 GDPR, you may only process criminal conviction data where EU or national law allows it. Many countries channel this through an official certificate, such as the Dutch VOG (VerklaringOmtrent het Gedrag) or the German Führungszeugnis, rather than direct checks.
• Proportionality. Collect only what the role justifies. A sales hire does not need the same checks as a cloud administrator.
• Transparency. Tell candidates what you check, why and for how long you keep the results.
• Works councils. In some countries, including the Netherlands and Germany, introducing or changing a screening policy may need works council involvement.
• DPIA. Systematic screening of staff often calls for a data protection impact assessment under Article 35 GDPR.

A workable process looks like this:

1. Map each role to a tier using your role matrix.
2. Define the check package per tier and per country of employment.
3. Inform the candidate and collect any consent or documents the country requires.
4. Run the checks and record the outcome and the decision.
5. Grant access only after the check is complete, and record the date.
6. Delete or archive results according to your retention schedule.

Step 5 is the one auditors test hardest, because it is the core of point 10.2.2(b).

Rescreening: when to check again

The Regulation sets no fixed rescreening interval, but it does create three moments when you must look again. First, the check must be complete before someone starts a screened role, so an internal move or promotion into Tier 1 or 2 triggers a new check. Second, point 10.1.3 requires a review of role assignments at least once a year. Third, point 10.2.3 requires the screening policy itself to be reviewed at planned intervals.

The annual role review is the natural moment to catch people whose access has grown since they were last screened. Combine it with your access rights review under point 11.2.3, so both use the same list of people.

Event triggers worth writing into your policy:

• An employee moves into a higher tier or gains privileged access.
• A security incident or policy breach involves the employee.
• A supplier contract is renewed or a supplier swaps the staff assigned to you.
• An employee returns after a long absence.
• National law changes what you are allowed or required to check.

For periodic rescreening, many organisations use a schedule like the one below. This is common practice, not a legal requirement; choose intervals your risk assessment can justify.

• Tier 1, privileged access: every 2 to 3 years
• Tier 2, sensitive access: every 3 to 5 years
• Tier 3, management body: on appointment and every 3 years
• Tier 4, general staff: on event triggers only

Audit evidence: what to keep

A supervisor or auditor will not accept a verbal assurance; they will ask for documents and then test a sample. Keep the following ready:

• A role matrix with screening tiers, approved by management. This proves criteria exist for which roles need verification (point 10.2.2(a)).
• A screening policy with version history and review dates. This proves the policy is reviewed at planned intervals (point 10.2.3).
• A record per person with the screening completion date and the access grant date. This proves checks happened before the person started the role (point 10.2.2(b)).
• A legal basis assessment, DPIA and retention schedule. This proves screening respects law and ethics (point 10.2.2(b)).
• Supplier contracts with screening clauses, plus supplier attestations. This proves supplier and contractor staff are covered (points 10.2.1 and 5.1.4(c)).
• An annual role assignment review record. This proves role assignments are reviewed at least once a year (point 10.1.3).
• An exceptions log with management risk acceptance. This proves any gap is a conscious, approved decision (point 2.1.1).

Expect a sample test. A typical one: take ten recent privileged hires and compare the date each check closed with the date each account was created. Any account created first is a finding. You can run this test yourself every quarter by joining your screening records to your identity provider's account creation log.

NIS2 and ISO 27001: reuse what you have

If you hold ISO 27001 certification, most of the groundwork is already in place. Annex A control 6.1 (Screening) of ISO/IEC 27001:2022 covers background checks before joining and on an ongoing basis, and maps directly to Annex point 10.2.

The gaps usually sit in three places:

• Explicit role criteria. ISO lets you describe screening in general terms; point 10.2.2(a) expects a list of roles that may only be held after verification.
• Timing. Point 10.2.2(b) is strict: the check is done before the person starts in the role, including internal moves.
• Suppliers. Point 5.1.4(c) expects screening requirements in supplier contracts, not just in your own HR process.

Close those three gaps and one screening process can serve both your ISO audit and your NIS2 supervisor.

Frequently asked questions

• Does NIS2 require criminal record checks?

Not for everyone. The Regulation's recitals name criminal record checks as one example of verification, where appropriate for the role. Whether you may request one depends on national law.

• Is Annex point 10.2 binding for my company?

It is binding if you are one of the eleven digital provider types covered by Regulation 2024/2690, such as a cloud provider or MSP. For other NIS2 entities, national law applies, and the Annex serves as a benchmark.

• Do we need to screen staff already in a role?

The Regulation has no transition rule for existing staff. A defensible approach is to screen current Tier 1 and Tier 3 role holders on a set schedule and document that plan.

• Do freelancers and supplier staff count?

Yes, where applicable. Point 10.2.1 covers direct suppliers and service providers, and point 5.1.4(c) asks you to put screening requirements in their contracts.

• How often should we rescreen?

The law sets no interval. Rescreen on role changes and other triggers, and pick periodic intervals that your risk assessment supports.

Screening for NIS2 with Pescheck

Pescheck runs pre-employment and in-employment screening across countries from one platform, with results and dates recorded for your audit trail. See how we support technology companies with NIS2 and ISO 27001 screening, or book a demo to set up your role-based screening packages.