Personnel Vetting

“Personnel with access to IT and OT assets are vetted at hire” is a simple sentence that drives real operational change. If your onboarding process can create accounts, badge access, VPN profiles, privileged roles, or OT logical access before screening clears, you are out of alignment with the requirement. The practical challenge is that vetting sits across HR, physical security, IT IAM, and OT operations, and each team often has its own systems and timelines.

This page converts the requirement into an implementable control: define who is in scope, define what “vetted” means in your organization, and build a workflow where HR (or the sponsoring manager) triggers checks early enough that IT/OT access is provisioned only after approval. You also need an exception path for urgent hires that still prevents access to sensitive assets until minimum screening is complete.

This guidance is written for a Compliance Officer, CCO, or GRC lead who needs to operationalize the personnel vetting requirement quickly, with audit-ready artifacts and clear ownership.

Regulatory text

Excerpt: “Personnel with access to IT and OT assets are vetted at hire.” (Cybersecurity Capability Maturity Model v2.1)

Plain-English interpretation

If a person will be able to access your IT systems or OT environment, you must run your hire-time screening process before you grant that access. “Vetted” is not defined in the excerpt, so you must define it, apply it consistently, and retain proof that vetting cleared before access was provisioned. The outcome auditors look for is straightforward: no access before screening approval, plus traceable evidence. (Cybersecurity Capability Maturity Model v2.1)

Who it applies to

In-scope entities and environments

• Energy sector organizations and other critical infrastructure operators using C2M2 to measure and improve cybersecurity capability maturity. (Cybersecurity Capability Maturity Model v2.1)
• Operational context: any environment where personnel can access:
  • IT assets (corporate networks, endpoints, email, cloud consoles, IAM, ticketing, code repos)
  • OT assets (SCADA/DCS interfaces, engineering workstations, historian access, jump hosts into OT, remote access to substations/plants)

In-scope people (do not stop at employees)

Treat “personnel” as a practical umbrella:

• Employees (full-time, part-time, interns)
• Contractors and consultants (third parties)
• Temporary staff
• Managed service provider personnel with access to your environments (third parties)
• Field service technicians with remote or on-site logical access to OT (third parties)

A reliable scoping rule: if they get a credential, a badge, a key, a token, a VPN profile, a privileged role, or any OT logical access path, they are in scope.

What you actually need to do (step-by-step)

Step 1: Define “vetted at hire” for your program

Write a short standard that answers:

• Which screening elements are required for IT/OT access roles (for example: identity verification, employment verification, criminal history check where lawful, sanctions/eligibility checks where relevant, reference checks for sensitive roles).
• Role-based depth: align the screening depth to access level (standard user vs. privileged admin vs. OT operator vs. OT engineer).
• Adjudication criteria: what findings trigger rejection, escalation, conditional hire, or restricted access.
• Jurisdiction handling: how you comply with local laws and what you do when a check is not permissible or not available.

Keep the standard implementable. If you cannot enforce it as a gate in provisioning, it is not a control.

Step 2: Build the vetting gate into onboarding (process + system)

You need a workflow that prevents access until “cleared”:

1. Trigger: hiring manager submits access needs (IT only, OT only, both; privileged vs. non-privileged).
2. Screening request: HR (or a designated screening function) initiates required checks.
3. Decision: designated adjudicator records “clear,” “clear with restrictions,” or “deny.”
4. Provisioning approval: IAM/IT service desk provisions accounts only after a recorded “clear.”
5. OT access activation: OT owner (often engineering/operations) enables OT logical access only after the same “clear.”

Minimum operational expectation: the “clear” status must be visible to the provisioning team, and provisioning must be blocked without it.

Step 3: Handle third parties explicitly

Third-party personnel are where many programs fail because the relationship owner assumes the staffing firm “handled it.” Make a decision and document it:

• Option A: You perform vetting for third-party individuals who will access IT/OT.
• Option B: The third party performs vetting, and you require evidence (attestation plus the right to inspect, or a defined evidence packet).

Either way, set a rule: no individual third-party access until vetting evidence is received and accepted.

Step 4: Define an exception path that still protects IT/OT

Urgent hires happen. If you allow exceptions, make them controlled:

• Limit exceptions to restricted access (for example: no OT access, no privileged roles, no remote access) until vetting completes.
• Require documented business justification and compensating controls (supervision, temporary credentials, enhanced logging).
• Time-box the exception operationally (by process), then automatically revoke if vetting does not clear.

Avoid “temporary” access that becomes permanent because nobody re-checks it.

Step 5: Align with access control and HR offboarding

Personnel vetting at hire is tightly coupled to access management:

• HR status should drive access eligibility.
• Role change should trigger re-evaluation if it materially increases IT/OT access risk.
• Terminations should remove access quickly and completely, including OT paths.

Even though this requirement is “at hire,” examiners often test whether your program behaves consistently across the identity lifecycle.

Required evidence and artifacts to retain

Audits go smoother when you can produce evidence per person, per onboarding event, with timestamps.

Core artifacts (retain centrally)

• Personnel vetting standard/procedure defining required checks by role and who adjudicates. (Cybersecurity Capability Maturity Model v2.1)
• Background screening request and completion records (or third-party attestation package) tied to the individual.
• Adjudication record showing decision, date, approver, and any restrictions.
• Access provisioning evidence showing access was granted after vetting cleared:
  • IAM approval tickets/work items
  • Account creation timestamps
  • Privileged access assignments
  • OT access enablement approvals
• Exception documentation (if used): justification, approver, restrictions, and follow-up closure.

Practical evidence tips (what examiners actually ask for)

• A sample of new hires mapped to:
  1. vetting completion date, and
  2. first access date.
     They want to see that vetting precedes access.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me the last set of hires with OT access. Where is the vetting proof?” (Cybersecurity Capability Maturity Model v2.1)
• “How do you prevent the service desk from creating accounts before clearance?”
• “Which third parties have remote access to OT, and how were their staff vetted?”
• “Who adjudicates findings, and what’s the escalation path?”
• “How do you handle hires in countries where certain checks are restricted?”

Common hangup: you have a policy, but provisioning is not technically or procedurally blocked. Auditors treat that as a control design gap.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Vetting exists, but it is not a gate

Symptom: HR completes screening “eventually,” while IT creates accounts on day one.
Fix: make “cleared” a required field/approval in the IAM or ticket workflow before provisioning.

Mistake 2: OT access is treated as separate and escapes HR controls

Symptom: engineering enables OT access locally with no HR signal.
Fix: require OT owners to use the same clearance status, or route OT access requests through a controlled workflow that checks clearance.

Mistake 3: Third-party staffing is handled by contract language only

Symptom: “The vendor does background checks” with no evidence collected.
Fix: require individual-level proof or a formal attestation plus audit rights, and do not issue credentials until received.

Mistake 4: No documented adjudication criteria

Symptom: inconsistent decisions, HR makes calls without security/operations context.
Fix: define who decides for higher-risk roles and document the rationale for non-clear outcomes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions.

From a risk standpoint, the control addresses insider threat, fraud, and unauthorized access risk. In OT environments, a single unvetted individual with engineering workstation or remote access can create safety, reliability, and operational disruption exposure. Treat vetting as part of your “access safety interlock,” not an HR formality. (Cybersecurity Capability Maturity Model v2.1)

Practical 30/60/90-day execution plan

Use this plan to stand up an audit-ready baseline quickly.

Day 0–30: Establish the control design

• Publish a short personnel vetting standard defining: scope, minimum checks, role tiers (IT, OT, privileged), adjudication owner, and required evidence. (Cybersecurity Capability Maturity Model v2.1)
• Map onboarding flow end-to-end (HR → IAM/service desk → OT access owners) and identify where access is granted today.
• Define third-party approach: who vets, what evidence you accept, and who reviews it.
• Create an exception process with required approvals and restricted-access rules.

Day 31–60: Implement gating and evidence capture

• Add a “Vetting Cleared” approval step to IAM/service desk workflows. Block provisioning without it.
• Implement a simple evidence repository (GRC tool, HR system export, or controlled folder with retention rules).
• Train service desk, OT access admins, and hiring managers on the new gate and what to do when clearance is pending.
• Run a small sample test: pick a few onboarding events and validate vetting dates precede provisioning dates.

Day 61–90: Expand coverage and prove operating effectiveness

• Extend gating to privileged access and OT access paths that were out-of-band.
• Start a monthly control check: reconcile “new access grants” vs. “vetting cleared.”
• Tighten third-party onboarding: ensure individual-level tracking for any credentialed access.
• Prepare an audit packet: policy, workflow screenshots, sample hires, and exception log.

Tooling note (where Daydream fits naturally)

If your pain point is evidence collection and demonstrating that clearance precedes access across HR, IT, and third parties, Daydream can act as the system of record for the requirement. Use it to standardize the evidence checklist, track third-party personnel attestations, and generate an audit-ready packet without chasing emails and screenshots.

Frequently Asked Questions

Does “vetted at hire” mean we must run criminal background checks for everyone?

The excerpt requires vetting but does not prescribe specific checks. Define a risk-based screening standard for roles with IT/OT access and apply it consistently, then retain proof that the defined vetting occurred. (Cybersecurity Capability Maturity Model v2.1)

Are contractors and consultants in scope for personnel vetting?

Yes if they receive access to IT or OT assets. You can vet them directly or require acceptable evidence from the third party, but access should not be granted until vetting is confirmed. (Cybersecurity Capability Maturity Model v2.1)

What counts as “access to OT assets”?

Any logical or credentialed path into OT systems is in scope, including jump hosts, remote access, shared engineering workstations, and accounts used to administer OT devices. Treat both on-site and remote logical access as access.

How do we handle urgent hires who need day-one access?

Use a documented exception path that grants restricted access only, with management approval and compensating controls. Remove the restriction only after vetting clears and record the closure of the exception.

What evidence is strongest for audits?

A per-person trail showing (1) vetting request, (2) vetting completion/clear decision, and (3) access provisioning timestamps after clearance. Add your written standard and any exception logs. (Cybersecurity Capability Maturity Model v2.1)

Can we accept an attestation letter from a staffing firm instead of underlying screening results?

You can set that as your acceptance standard, but make it explicit what the attestation must cover and who reviews it. Ensure your process still blocks access until the attestation is received and approved.