Cybersecurity Training

The cybersecurity training requirement means you must provide role-appropriate security training to every person who can access your IT and OT assets, and you must be able to prove it with records. Operationalize it by defining the in-scope population, assigning training by role and asset access, tracking completion, and testing effectiveness through exercises and follow-up actions. (Cybersecurity Capability Maturity Model v2.1)

Key takeaways:

• Scope is access-based: if someone can touch IT or OT, they must be trained. (Cybersecurity Capability Maturity Model v2.1)
• “Provided” must be provable: completion logs, content, assignments, exceptions, and remediation actions matter. (Cybersecurity Capability Maturity Model v2.1)
• OT requires tailored scenarios: generic office phishing content rarely covers control-room realities. (Cybersecurity Capability Maturity Model v2.1)

Cybersecurity training is one of those controls that looks simple until you try to defend it in an audit, an incident postmortem, or a board briefing. The C2M2 requirement is short, but it creates several operational obligations: you must know exactly who has access to IT and OT assets, you must deliver training that matches that access, and you must retain evidence that the right people received the right training. (Cybersecurity Capability Maturity Model v2.1)

For energy and other critical infrastructure operators, the OT angle changes the execution. Training has to reach not only corporate users but also operators, technicians, engineers, and third parties who connect to plant networks, use jump hosts, carry engineering workstations, or access historian and SCADA environments. If your training program ignores those workflows, you will end up with “completion” that does not reduce operational cyber risk. (Cybersecurity Capability Maturity Model v2.1)

This page translates the requirement into a practical checklist: how to scope personnel, build role-based training, operationalize assignments and tracking, and maintain an evidence set that stands up to scrutiny.

Regulatory text

Requirement (excerpt): “Cybersecurity training is provided to personnel with access to IT and OT assets.” (Cybersecurity Capability Maturity Model v2.1)

What the operator must do:

• Identify all personnel (employees and non-employees) who can access IT or OT assets. (Cybersecurity Capability Maturity Model v2.1)
• Provide cybersecurity training to that population, in a form appropriate to their access and responsibilities. (Cybersecurity Capability Maturity Model v2.1)
• Maintain records that demonstrate training delivery and participation for the in-scope population. (Cybersecurity Capability Maturity Model v2.1)

Plain-English interpretation (what “counts”)

You meet the cybersecurity training requirement when you can show: (1) you have a complete and current list of people with IT/OT access, (2) each person is assigned training aligned to their role and access, (3) training is actually delivered and tracked, and (4) training outcomes feed back into operations (for example, targeted refreshers after incidents or recurring errors). (Cybersecurity Capability Maturity Model v2.1)

A training video in the LMS is not the control. The control is a managed training process tied to access to IT and OT assets. (Cybersecurity Capability Maturity Model v2.1)

Who it applies to (entity and operational context)

Organizations: Energy sector organizations and critical infrastructure operators using C2M2 to measure and improve cyber capability. (Cybersecurity Capability Maturity Model v2.1)

In-scope personnel: Anyone with access to IT or OT assets, including:

• Corporate users with IT access (endpoints, email, SaaS, internal apps). (Cybersecurity Capability Maturity Model v2.1)
• OT engineers/operators/technicians with access to plant networks, control systems, or engineering tools. (Cybersecurity Capability Maturity Model v2.1)
• Third parties such as contractors, integrators, OEM support, and consultants with remote or onsite connectivity, credentials, or physical access that enables cyber interaction with assets. (Cybersecurity Capability Maturity Model v2.1)

Common scoping edge cases to decide explicitly:

• Shared accounts in OT. If training is tied to accounts, shared credentials break traceability. Treat this as a training and access governance gap. (Cybersecurity Capability Maturity Model v2.1)
• “Occasional” access (outage support, emergency call-in). If access can happen, training must be available before access is granted. (Cybersecurity Capability Maturity Model v2.1)

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

1) Define “access to IT and OT assets” in your environment

Write a short, defensible definition used by HR, IAM, OT operations, and third-party onboarding. Include at least: credentialed access, privileged access, remote access pathways, physical access enabling console/serial connections, and use of managed endpoints connected to OT. (Cybersecurity Capability Maturity Model v2.1)

Output: Training scope statement that can be reused in policy, onboarding checklists, and audit narratives. (Cybersecurity Capability Maturity Model v2.1)

2) Build your in-scope population list (and keep it current)

Pull from systems that approximate “access,” not org charts: IAM groups, VPN/RDP/jump host rosters, badge access for control rooms, OT domain accounts, EAM/CMMS contractor lists, and vendor remote support approvals. (Cybersecurity Capability Maturity Model v2.1)

Practical approach: create a single “training eligibility feed” that merges:

• HR roster (employees)
• Identity directory / IAM (accounts)
• Third-party registry (non-employees)
  Then reconcile exceptions (inactive accounts, shared accounts, emergency accounts). (Cybersecurity Capability Maturity Model v2.1)

3) Create role-based training tracks tied to access

Map roles to training modules. Keep the mapping simple enough to administer, but specific enough to address OT realities. Example training tracks:

• General IT user: phishing, password hygiene, incident reporting, data handling. (Cybersecurity Capability Maturity Model v2.1)
• Privileged IT admin: MFA and privileged access handling, change control, secure remote admin, logging expectations. (Cybersecurity Capability Maturity Model v2.1)
• OT operator/technician: removable media rules, vendor laptop handling, alarm/reporting paths, safety vs cyber escalation, remote access boundaries, consequences of “quick fixes” on HMIs/engineering workstations. (Cybersecurity Capability Maturity Model v2.1)
• OT engineer/control system engineer: secure configuration practices, backup/restore expectations, approved software and project file handling, segmentation basics, remote session recording expectations. (Cybersecurity Capability Maturity Model v2.1)
• Third party with remote access: session rules, tool restrictions, data transfer approvals, incident reporting, credential handling, and “stop work” triggers. (Cybersecurity Capability Maturity Model v2.1)

Decision rule: training assignment should be triggered by access grant. If someone is provisioned to a jump host group, that assignment should automatically attach the right training. (Cybersecurity Capability Maturity Model v2.1)

4) Deliver training through controlled channels and verify completion

Use an LMS or equivalent system that can: assign by group, capture completion, and preserve evidence. For OT teams without desks, plan delivery options that still produce trackable evidence (kiosk sign-in, supervised sessions with attestations, or mobile-compatible modules). (Cybersecurity Capability Maturity Model v2.1)

Add an “access gate”: if feasible, make certain access conditional on training completion, especially remote access and privileged access. If you cannot gate access technically, implement a documented manual approval check. (Cybersecurity Capability Maturity Model v2.1)

5) Prove effectiveness, not just completion

C2M2’s text is short, but audits often probe whether training changes behavior. Build lightweight feedback loops:

• Phishing simulations for IT users, with targeted retraining for repeat failures. (Cybersecurity Capability Maturity Model v2.1)
• Tabletop scenarios for OT (for example, vendor remote session goes off-script; engineering workstation malware suspicion; removable media discovery). Track lessons learned and resulting procedural changes. (Cybersecurity Capability Maturity Model v2.1)
• Short “reporting drills” so personnel practice how to escalate suspected cyber events through the right channels. (Cybersecurity Capability Maturity Model v2.1)

6) Manage exceptions and remediation cleanly

Define what happens when training is overdue, skipped, or unavailable for a role. Document:

• Temporary access with compensating controls (named approver, time-bounded, increased monitoring). (Cybersecurity Capability Maturity Model v2.1)
• Retraining after policy violations or incidents. (Cybersecurity Capability Maturity Model v2.1)
• Handling for third parties who refuse your training (contract clause, alternate training attestation, or denial of access). (Cybersecurity Capability Maturity Model v2.1)

7) Operationalize with ownership and cadence

Assign clear owners: compliance/GRC for governance, security awareness lead for content, HR for onboarding hooks, IAM/OT access administrators for access-triggered assignments, and vendor management for third-party onboarding/offboarding. (Cybersecurity Capability Maturity Model v2.1)

If you use Daydream to manage third-party risk workflows, treat training as a third-party onboarding control: require proof of completion or attestation before remote access approvals, and store the artifacts with the third party record for fast retrieval during audits. (Cybersecurity Capability Maturity Model v2.1)

Required evidence and artifacts to retain

Maintain an evidence set that answers three questions: who was in scope, what did they take, and did they complete it. (Cybersecurity Capability Maturity Model v2.1)

Core artifacts (keep current):

• Training policy/standard defining in-scope personnel as “access to IT and OT assets.” (Cybersecurity Capability Maturity Model v2.1)
• Role-to-training matrix showing required modules by access type (IT user, OT operator, privileged admin, third party remote support). (Cybersecurity Capability Maturity Model v2.1)
• Training content inventory (titles, descriptions, version history, learning objectives). (Cybersecurity Capability Maturity Model v2.1)
• Assignment rules (LMS group mapping, IAM group triggers, onboarding workflow). (Cybersecurity Capability Maturity Model v2.1)
• Completion reports with dates, user identity, module, status; include population reconciliation for third parties and OT shift workers. (Cybersecurity Capability Maturity Model v2.1)
• Exception register (who, why, approver, compensating controls, expiration). (Cybersecurity Capability Maturity Model v2.1)
• Exercise records (OT tabletop agendas, attendance, findings, corrective actions). (Cybersecurity Capability Maturity Model v2.1)

Common exam/audit questions and hangups

Expect auditors to test scope and traceability more than content quality. Typical questions:

• “Show me your universe of personnel with IT and OT access, including contractors.” (Cybersecurity Capability Maturity Model v2.1)
• “How do you ensure OT staff and third parties receive training before access is granted?” (Cybersecurity Capability Maturity Model v2.1)
• “How do you track training for shared accounts or shift-based OT roles?” (Cybersecurity Capability Maturity Model v2.1)
• “Provide evidence that your training content is relevant to OT workflows.” (Cybersecurity Capability Maturity Model v2.1)
• “What happens if someone is overdue? Show enforcement and exceptions.” (Cybersecurity Capability Maturity Model v2.1)

Hangup to anticipate: your HR roster will not match your access roster. Plan to explain reconciliation logic and show periodic reviews. (Cybersecurity Capability Maturity Model v2.1)

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating training as an annual check-the-box activity.
  Avoid it by tying training assignment to provisioning events and adding targeted refreshers after incidents or recurring errors. (Cybersecurity Capability Maturity Model v2.1)

• Mistake: OT training equals IT training.
  Avoid it by adding OT-specific modules and scenarios focused on removable media, remote support, engineering workstations, and escalation paths aligned to operations. (Cybersecurity Capability Maturity Model v2.1)

• Mistake: Ignoring third parties because “they’re not employees.”
  Avoid it by making training/attestation a prerequisite for remote access approval and by storing evidence alongside third-party access approvals. (Cybersecurity Capability Maturity Model v2.1)

• Mistake: No evidence trail for exceptions.
  Avoid it with an exception register and time-bounded approvals tied to compensating controls. (Cybersecurity Capability Maturity Model v2.1)

• Mistake: No control over training versions.
  Avoid it with versioned content and a record of which version each person completed, especially after major policy changes. (Cybersecurity Capability Maturity Model v2.1)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. (Cybersecurity Capability Maturity Model v2.1)

Operationally, weak training shows up as predictable failure modes: mishandled credentials, unsafe remote support, poor incident reporting, and OT workarounds that bypass segmentation or change control. Your risk is not “training noncompliance” in the abstract; it is preventable cyber pathways created by people who have access to assets but lack role-specific guidance and practice. (Cybersecurity Capability Maturity Model v2.1)

A practical 30/60/90-day execution plan

Because timelines depend on staffing, tooling, and workforce size, use these as phases with clear deliverables rather than calendar promises. (Cybersecurity Capability Maturity Model v2.1)

First phase (immediate): get scope and proof mechanics right

• Publish a one-page scope definition for “personnel with access to IT and OT assets.” (Cybersecurity Capability Maturity Model v2.1)
• Build the initial in-scope roster by reconciling HR, IAM, OT accounts, and third-party access lists. (Cybersecurity Capability Maturity Model v2.1)
• Stand up a completion reporting mechanism (LMS export or equivalent) that can be produced on demand. (Cybersecurity Capability Maturity Model v2.1)
• Create an exception process and register, with approvers and compensating controls. (Cybersecurity Capability Maturity Model v2.1)

Second phase (near-term): implement role-based tracks and access-triggered assignment

• Define training tracks for IT users, OT operators/engineers, privileged admins, and third parties. (Cybersecurity Capability Maturity Model v2.1)
• Map each track to access groups (VPN, jump host, OT domain, privileged roles) and implement assignment rules. (Cybersecurity Capability Maturity Model v2.1)
• Add third-party onboarding steps so training/attestation is collected before access. Store evidence with the third-party record (Daydream can centralize these artifacts for retrieval). (Cybersecurity Capability Maturity Model v2.1)

Third phase (ongoing): measure effectiveness and close gaps

• Run at least one OT-focused tabletop and track corrective actions to closure. (Cybersecurity Capability Maturity Model v2.1)
• Establish a routine review of roster completeness (new hires, terminated users, contractor offboarding, dormant accounts). (Cybersecurity Capability Maturity Model v2.1)
• Refresh content when policies or access methods change, and maintain version history. (Cybersecurity Capability Maturity Model v2.1)

Frequently Asked Questions

Does this requirement include contractors and vendors?

It applies to “personnel with access to IT and OT assets,” which includes third parties if they have access. Treat training or documented attestation as a prerequisite to granting or renewing access. (Cybersecurity Capability Maturity Model v2.1)

What counts as OT-focused cybersecurity training?

Training should reflect OT workflows and failure modes, such as removable media handling, vendor remote support rules, engineering workstation hygiene, and clear escalation paths for suspected cyber events. Document the OT modules and who they are assigned to. (Cybersecurity Capability Maturity Model v2.1)

We have shared accounts in OT. How can we show training compliance?

Shared accounts break traceability. Short term, maintain attendance attestations tied to the individuals who use those accounts and restrict shared credential use with documented approvals; longer term, work toward named accounts so training can map to access. (Cybersecurity Capability Maturity Model v2.1)

How do we “prove” training was provided if we do in-person sessions?

Keep sign-in sheets or electronic attestations, the session agenda, the training materials, and a roster reconciliation showing all in-scope personnel attended or were assigned an equivalent module. Store these records centrally for audit retrieval. (Cybersecurity Capability Maturity Model v2.1)

Should training be required before access is granted?

If you can, yes. The requirement focuses on personnel with access, so gating access on completion is a clean control design; if you cannot gate technically, document a manual approval step and track exceptions. (Cybersecurity Capability Maturity Model v2.1)

How do we handle third parties who refuse our training content?

Decide upfront whether you accept an equivalent attestation, require your training as a contract term, or deny access. Document the decision and retain the evidence with the third-party access approval record. (Cybersecurity Capability Maturity Model v2.1)