- The role list as it actually is — who administers, who develops, who runs the plant, who responds
- Whatever training already happens, however informal — toolbox talks, vendor sessions, lunch-and-learns
- A place to keep completion evidence: LMS exports, signed rosters, dated notes
ATL-030MATRIXEDITORIAL REVIEW COMPLETE
Security Training Matrix
A role-by-role training matrix — everyone, admins, developers, OT operators, incident responders, executives — with topics, frequency, delivery method, and completion evidence per row, built for organizations where a documented toolbox talk at the line counts as training because it is training.
Using this artifact
Purpose, inputs, and completion
Purpose. Awareness training fails when one generic module is stretched across every job in the building — the admin learns nothing new and the operator learns nothing relevant. This matrix assigns each role the topics its mistakes would actually cost, sets a frequency and a delivery method that fit how that role works, and demands dated completion evidence per row. It turns 'we do training' into a schedule with names on it.
When to use it. Adapt the example rows to your roles, deleting what you do not have and resisting the urge to add roles you cannot maintain. Deliver each row the way that role actually absorbs information — modules for the office, documented toolbox talks at the line — and file the evidence as each cycle completes. Review the matrix annually and the completion columns monthly; the next-due column is the program's heartbeat.
- Seed each role's topics from the example rows, then cut what does not apply — a six-role matrix nobody maintains loses to a four-role matrix everyone does.
- Keep phishing awareness and insider-threat indicators in the everyone-row every cycle; those two are the front door of the campaign.
- Count what already happens: a documented toolbox talk on USB hygiene at the line is operator training — write it in with a date and the sign-in sheet.
- Track last-completed and next-due per row and chase the overdue monthly; an undated matrix is a poster.
Keeping it honest
Evidence, validation, and failure modes
- A role-by-role training matrix with frequencies and delivery methods
- Dated completion evidence per role and cycle
- A next-due schedule showing the program runs rather than merely exists
- Pick two people at random and produce their last completion evidence within ten minutes; if it takes longer, the evidence system is the gap.
- Check the everyone-row: phishing awareness and insider-threat indicators both appear, with a completion date inside the current cycle.
What looks done but is not
- Training is annual-everything-for-everyone, so admins never see admin-specific content and operators sit through office-phishing modules irrelevant to the line.
- Toolbox talks happen weekly but are never documented, so real training produces no evidence anyone can point to.
- The matrix is built once, roles drift, and the new developer is six months in with no security onboarding row.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain completion evidence for at least the current and previous cycle per person; a reviewer asks not whether training exists, but whether these specific people completed it, and when.
Full document
Preview — exactly what prints
MATRIX · TRAINING & WORKFORCEv1.0 · REVIEWED 2026-08-06
Security Training Matrix
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Awareness training fails when one generic module is stretched across every job in the building — the admin learns nothing new and the operator learns nothing relevant. This matrix assigns each role the topics its mistakes would actually cost, sets a frequency and a delivery method that fit how that role works, and demands dated completion evidence per row. It turns 'we do training' into a schedule with names on it.
How to use it
Adapt the example rows to your roles, deleting what you do not have and resisting the urge to add roles you cannot maintain. Deliver each row the way that role actually absorbs information — modules for the office, documented toolbox talks at the line — and file the evidence as each cycle completes. Review the matrix annually and the completion columns monthly; the next-due column is the program's heartbeat.
How to use the matrix
Each row is a role, not a person; people holding two roles complete both rows. Topics are what the role's mistakes would cost the company: the everyone-row defends against phishing and insider risk because every mailbox is a target, while the admin row exists because one privileged mistake outweighs a hundred ordinary ones.
Toolbox talks count — when documented
Plant-floor reality: operators do not sit through webinars, and they do not need to. A ten-minute toolbox talk at shift start — USB hygiene, what an abnormal HMI looks like, who to call before touching a suspect system — is legitimate training when it is dated, topical, and signed. The sign-in sheet is the completion evidence; without it, the talk happened and the training did not.
Training matrix
Seeded with example rows for the six common roles — adapt the topics, keep the discipline of the last two columns.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Role | Required training topics | Frequency | Delivery method | Completion evidence | Last completed | Next due |
|---|---|---|---|---|---|---|
| EXAMPLE: Everyone | Phishing awareness; insider-threat indicators and how to report them; data handling basics; the incident reporting path | Annual + at onboarding | Short online module + quarterly phishing exercise | LMS export; exercise results | 2026-05-12 | 2027-05-12 |
| EXAMPLE: System administrators | Privileged-account hygiene; MFA administration; log review; change discipline | Annual + at role change | Instructor-led or vendor course | Certificate or dated attendance record | 2026-03-20 | 2027-03-20 |
| EXAMPLE: Developers | Secure coding basics; secrets handling; dependency awareness; AI-tool data rules (ATL-029) | Annual | Course + team review of the AI register | Course record; review meeting notes | 2026-04-08 | 2027-04-08 |
| EXAMPLE: OT operators | USB and removable-media hygiene at the line; recognizing abnormal HMI behavior; who to call before touching a suspect system | Quarterly toolbox talks | Documented toolbox talk at shift start | Signed, dated toolbox-talk sheets | 2026-06-03 | 2026-09-03 |
| EXAMPLE: Incident responders | Plan walkthrough (ATL-021); timeline discipline (ATL-022); evidence-preservation basics | Annual tabletop + after plan changes | Tabletop exercise | Exercise report with attendee list | 2026-02-11 | 2027-02-11 |
| EXAMPLE: Executives | Incident decision authority; the 72-hour reporting decision (ATL-023); what approving an exception actually commits | Annual briefing | One-hour briefing with the tabletop | Dated briefing note with attendees | 2026-02-11 | 2027-02-11 |
Completion evidence
Evidence answers one question fast: did this person complete this training, and when? Pick the lightest format that answers it.
What counts as completion evidence
- LMS or module exports
- Name, module, date, result — exported and filed per cycle, not left inside a tool whose subscription may lapse.
- Signed rosters and toolbox-talk sheets
- Topic, date, presenter, signatures. A binder of these is a perfectly good evidence system for a plant.
- Exercise and tabletop reports
- Scenario, date, attendee list, and what the exercise changed — the change list doubles as the improvement record.
- Dated briefing notes
- For executive sessions: one page, topics covered, who attended, who presented.
Tracking log
| Person | Role row | Training completed | Date | Evidence location |
|---|---|---|---|---|
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | Executive sponsor or HR lead |
| Approval authority | Executive sponsor |
| Review frequency | Annual for the matrix itself; completion tracking monthly until every row shows current |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain completion evidence for at least the current and previous cycle per person; a reviewer asks not whether training exists, but whether these specific people completed it, and when. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.