AT.L2-3.2.2Role-based Training
Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.
[a]
information security-related duties, roles, and responsibilities are defined;[b]
information security-related duties, roles, and responsibilities are assigned to designated personnel; and[c]
personnel are adequately trained to carry out their assigned information securityrelated duties, roles, and responsibilities.
Security duty matrix: every named role has a training plan and a due date
Implementation
AO coverage. Addresses all Role-based Training objectives: defining security duties, assigning them to named people, and training those people to perform them.
Defining duties. A duty matrix lists every security-related responsibility the program depends on — log review, vulnerability triage, access approval, backup restore testing, incident commander, evidence custodian, physical access administration, and vendor security review. Each row states what the duty is, how often it is exercised, and what competence it requires. Duties came out of the practice-by-practice walkthrough of the SSP rather than from a job-description template.
Assigning duties. Every row names a primary and a backup individual by role and by person. Two-deep coverage is a hard rule for duties that cannot wait a week: incident commander, backup restore, and access approval. Where the duty sits with the managed service provider, the row names the provider function and the internal person accountable for verifying it.
Training to the duty. Each duty maps to a training plan rather than a generic course: vendor administration training for the platform involved, a documented shadow period with the current holder, and a sign-off that the person performed the task unaided once. The ISSO holds an external certification; the incident commander backup completed a tabletop-focused course. Completion and expiry dates live in the LMS with the duty ID.
Maintenance. The matrix is reviewed twice a year and immediately when someone changes role. An unassigned or single-deep critical duty is a finding tracked to closure like any other. Onboarding into a role opens a ticket that will not close until the shadow period sign-off is attached.
Accepted gap. Vulnerability triage depth is thinner than we would like: the primary is competent, the backup can execute the runbook but not judge exploitability. Until a second engineer is trained, the managed service provider retainer covers escalation, and that dependency is stated in the matrix.
What the evidence looks like
- Security duty matrix with primary/backup assignments and review dates
- LMS transcript filtered to duty-linked training with completion and expiry
- Shadow-period sign-off for a recently assigned duty
- Ticket showing a role change triggering a matrix update
- Provider retainer language covering the escalation dependency
Environment
Tools
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.