Official intent
Keep the technical workforce running your defenses current and practiced through continuous, role-based readiness. The official source remains authoritative.
Read the official campaign ↗Tools do not defend anything on their own — people operate them. Continuous readiness means role-based training for the staff who run identity, endpoints, cloud, and response; hands-on exercises that build muscle memory; and keeping pace as your stack and the threats change. It is the cheapest of the basics and the one that makes the rest work.
Who this applies to: Universal, and disproportionately valuable in small teams where one person holds several roles and there is no bench.
Why it matters
A misconfigured control or a missed alert undoes expensive tooling. The people running your defenses need current, role-specific skills — not a once-a-year slideshow — and the confidence that comes from practicing before a real incident. Readiness also reduces key-person risk, so one departure does not blind your program.
Risks this reduces
- Misconfigured controls caused by staff operating tools they were never trained on
- Missed or misjudged alerts during an incident
- Key-person dependency where one departure blinds the programme
- Response improvised under pressure because it was never rehearsed
Who owns it
Executive sponsor
IT leader, Security lead, Team leads
Low
Low
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: nothing else on the list. You can start this today.
- A written statement of who operates each core defensive capability today
- Budget and released time for training — the constraint is usually time, not cost
- A defined set of technical roles rather than a single 'IT' bucket
Action timeline
- List who runs each core defense (identity, endpoints, backup, response)
- Identify any single-person dependencies
- Map each core defense — identity, endpoints, backup, response — to the person who operates it and mark every single-person dependency
- Book the first role-based training against your largest gap rather than the most convenient course
- Map each technical role to the skills it needs
- Schedule role-based training for the biggest gaps
- Run a tabletop exercise for a likely incident
- Begin cross-training on critical functions
- Track skills and training completion
- Fold exercise lessons into runbooks and the training plan
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Define the technical roles that operate your defenses and who holds each today.
- Map each role to the specific competencies it requires and identify the gaps.
- Schedule role-based training — hands-on where possible — against those gaps.
- Practice with tabletop and hands-on exercises so skills are rehearsed before an incident.
- Cross-train critical functions and track readiness so it keeps pace with your stack and the threat.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
General awareness training only; technical staff get nothing role-specific.
Is there anything at all — a tool, a document, a person who owns it? - Documented
Technical roles and the competencies each requires are written down, with the gaps identified.
Is the intent written down, with a named owner and a scope? - Configured
Role-based training is scheduled and budgeted against the largest gaps.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Staff in technical roles have completed the training their role requires, and cross-training has started.
Does it cover everything in scope, with the exceptions written down? - Measured
Skills coverage and exercise outcomes are tracked, and lessons demonstrably change runbooks.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
An owner maintains the roles-to-skills plan, reviews it as the stack changes, and retains completion evidence.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Confirm each critical defense has more than one person able to operate it.
- Verify role-based training was completed for staff in technical roles this cycle.
- Check that the last exercise produced documented lessons that changed a runbook or plan.
Evidence to retain
Roles-to-skills plan and training policy
Training records mapped to technical roles
Exercise reports and cross-training coverage
Skills/readiness tracker and post-exercise improvement log
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Single-person dependencies | Critical capabilities with only one competent operator. | Zero. |
| Role-based training completion | Technical staff current on their role's required training ÷ technical staff. | Above 90% each cycle. |
| Exercise-to-improvement rate | Exercises that produced a documented change to a runbook or plan ÷ exercises run. | 100% — an exercise that changes nothing was not a test. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
One annual awareness video counted as technical training, a single person who is the only one who understands a critical system, and exercises that generate slides but never change a runbook. Readiness that is never practiced is a resume, not a capability.
Two sized paths
Name who runs identity, endpoints, backup, and response — even if it is the same person or your MSP — and make sure a second person can do each one. Run one two-hour tabletop a year. Use free vendor training and the no-cost DIB programmes before buying courseware.
Maintain a role-to-competency matrix with tracked currency, run scenario exercises that include leadership and third parties, and feed every exercise finding into runbooks, tooling, or the training plan so readiness compounds rather than resets.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Readiness has to keep pace with the stack. Add a training and cross-training check to the adoption of any new security platform, so a tool never goes live with exactly one person who understands it.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The CMMC practices inherit the 800-171 requirement text directly.
What this does not claim: Supports the requirement; it does not satisfy it on its own and does not establish an assessment outcome. Scope, implementation quality, and evidence decide that.
Why: CIS calls for role-specific security awareness and skills training beyond the general programme.
What this does not claim: CIS is a voluntary benchmark. Alignment with it carries no contractual weight.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.2.1Role-appropriate security awarenessDirect implementation supportHigh
Why: The requirement names managers, systems administrators, and users as the populations to be made aware of security risks; the practice's role mapping and recurring training rhythm work directly on the administrator and manager slices of that population.
What this does not claim: Supports implementation of the requirement for the technical and leadership roles the practice concentrates on; the general user population's awareness program is separate work the practice does not carry. Records for the whole population, not just technical staff, are what an assessor examines within the organization's defined system boundary.
Review status: Technical review complete.
Open the 3.2.1 page →3.2.2Security duty trainingDirect implementation supportHigh
Why: Training personnel to carry out their assigned security duties is precisely this practice's core activity: a roles-to-competencies map, role-based training booked against the largest gaps, and cross-training so no duty is one person deep.
What this does not claim: Supports implementation of the requirement; it does not decide an assessment outcome on its own. Security duties also sit outside the technical team — HR handling terminations, shipping handling marked media — and those roles need duty training the practice as written does not reach.
Review status: Technical review complete.
Open the 3.2.2 page →NIST SP 800-171 Rev. 3
03.02.01Literacy Training and AwarenessDirect implementation supportModerate
Why: A workforce readiness program that trains people on a rhythm and updates content as the threat picture changes is the operating engine this requirement's literacy training runs on — the cadence, the triggers, and the records are shared machinery.
What this does not claim: The requirement names its content: recognizing and reporting insider-threat indicators, social engineering, and social mining, delivered to all system users. The practice centers on technical-staff readiness; unless the general-user curriculum actually carries those named topics, the relationship is partial rather than direct. Coverage of every user population — not just the technical team — must also be demonstrable.
Review status: Pending NIST SME review.
Open the 03.02.01 page →03.02.02Role-Based TrainingDirect implementation supportHigh
Why: Role-based training is the practice's core substance: mapping security-relevant roles to required competencies, training before duties begin, and refreshing as the stack changes is what both the practice and the requirement describe.
What this does not claim: The requirement covers everyone with security-relevant duties, including non-technical roles — the person who approves accounts, the office manager who handles visitor access — and outsourced ones; a program scoped only to the IT team leaves those populations unaddressed. Timing matters too: training must precede access and duties, which a catch-up program does not demonstrate.
Review status: Pending NIST SME review.
Open the 03.02.02 page →Review status
| Technical review | Reviewed |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.0 |