AT-3 is the control that says one annual slideshow is not enough. People who write code, run databases, approve access or respond to incidents need training that fits those jobs, and they need it before they start the work.
NIST SP 800-53 Rev 5 binds US federal systems, and it reaches other organizations through contracts. For everyone else it is a reference. If a customer or auditor asks how you train engineers or administrators, AT-3 is a useful way to frame the answer.
What the control asks
The control has three parts. Provide role-based security and privacy training to personnel with defined roles and responsibilities. Give that training before the person gets access or starts their duties, again at an interval you set, and whenever the system changes in ways that matter. Then keep the content alive: update it on a schedule and fold in lessons from internal or external incidents and breaches.
NIST leaves the roles, the frequency and the update triggers to you. Those are organization-defined values, so your policy has to state them.
What it means in practice
NIST's guidance lists the kinds of roles it has in mind. For a software company the useful ones are:
- Developers, who need secure coding and dependency handling.
- System, network and database administrators, who need hardening and access practices.
- People with incident response and contingency duties.
- Anyone with access to personal data or to system level software.
- Managers and system owners who accept risk.
- Auditors and assessors who test controls.
Each role gets content that fits it. A developer course on injection and secrets handling is role-based. A generic phishing video is awareness training, which is a different control (AT-2).
The "before access" clause matters. If a new engineer gets production access in week one and training in week six, you have a gap an auditor can measure from your own records.
Evidence to collect
- A role matrix: each role, the training it requires, and the frequency.
- Course content or syllabi for each role, with a version or date.
- Completion records per person, with dates, that you can compare to access grant dates.
- Results of any assessments, not only attendance.
- A change log showing when content was updated and why.
- At least one example where an incident or near miss changed the material.
Common gaps
- One course for everybody, with no distinction by role.
- Training completed after access was granted.
- No record of why the content changed, or no change for years.
- No trigger for retraining when a system changes.
- Contractors and admins left out of the roster.
- Incident lessons discussed in a meeting but never written into training.
How to implement it
Start with the role matrix, because everything else hangs on it. Pull the list of roles from your access system, not from memory. Define the minimum training per role and set a retraining interval you can keep. Annual is common.
Next, tie training to onboarding. Make completion a prerequisite in the access request for production systems, or at least a check performed within a set number of days. Then write the update rule: review content at least once a year and after any significant incident, and record the review even when nothing changed.
The enhancements show where you can go deeper: AT-3.3 Practical Exercises for hands-on work, AT-3.4 Suspicious Communications and Anomalous System Behavior, and AT-3.5 Processing Personally Identifiable Information for roles that handle personal data. Adopt them where the role warrants it.
Quick check
A new developer gets production access on day two and finishes role training on day nine. Is that a finding?
Likely yes. AT-3 asks for training before access is authorized or duties begin. Either delay access or define a short, documented exception process and review it.
Does an attendance list count as evidence?
It shows participation, but an auditor will often want content and some proof the material was understood. Keep both.
