AT-2(1): Practical Exercises

AT-2(1) requires you to add hands-on, scenario-based practical exercises to your security literacy training so personnel practice responding to realistic events and incidents, not just watch slides. To operationalize it, define exercise scenarios tied to your risk profile, run them on a cadence, track participation and outcomes, and retain evidence that exercises occurred and drove corrective actions. ¹

Key takeaways:

• Practical exercises must simulate real events/incidents relevant to your environment, not generic awareness content. ¹
• Auditors will look for execution evidence: scenarios, rosters, results, and follow-up actions, not just a training policy. ²
• Treat exercises as an operational control: defined owner, documented procedure, repeatable artifacts, and measurable outcomes.

The at-2(1): practical exercises requirement sits inside NIST SP 800-53’s Awareness and Training (AT) family and is easy to misunderstand. Many programs stop at “annual training” and a phishing module. AT-2(1) asks for something more operational: practical exercises that simulate events and incidents so people rehearse the actions you expect during real security situations. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat AT-2(1) like a mini-exercise program: define a small set of scenarios mapped to your most likely incident types, run short drills with the right roles, capture what happened, and document improvements. Your goal is assessability. You need to prove (1) exercises occurred, (2) they were realistic and role-appropriate, and (3) you used results to strengthen procedures and reduce repeat mistakes.

This page gives requirement-level implementation guidance you can put into a control narrative, assign to an owner, and run without turning it into a full-scale business continuity program.

Regulatory text

Requirement (excerpt): “Provide practical exercises in literacy training that simulate events and incidents.” ¹

What the operator must do: incorporate hands-on exercises into your security literacy training program where personnel must respond to realistic simulated security events/incidents (for example: reporting suspected phishing, handling a lost device, responding to a suspected data spill, escalating suspicious activity). The exercises must be run, tracked, and evidenced as part of training operations, not left as an informal “tabletop sometime.” ²

Plain-English interpretation

AT-2(1) means: “People learn security by doing.” You must give personnel practice runs that mirror how a real incident unfolds in your environment, so they rehearse the exact behaviors your policies and incident procedures require.

A practical exercise is different from:

• Passive training: videos, slide decks, reading acknowledgements.
• Policy attestation: “I agree” checkboxes.
• One-off awareness events: ad hoc lunch-and-learns with no records.

AT-2(1) is satisfied when you can show repeatable simulations tied to incident response expectations, with participation records and outcomes that feed back into improved processes.

Who it applies to

Entity types (typical):

• Federal information systems.
• Contractor systems handling federal data. ²

Operational context: any system boundary where NIST SP 800-53 controls are in scope (for example, an information system supporting a federal mission, or a contractor environment processing federal information). If your workforce includes employees, temps, and long-term contractors with system access, they are usually in the training population for exercises, at least for role-relevant scenarios.

Roles most directly impacted:

• All users (baseline “report and escalate” drills).
• Privileged users (admin-focused scenarios).
• Security operations / IR team (triage and escalation drills).
• Help desk (first-contact scripts and ticket handling).
• HR and Legal/Privacy (where incident playbooks require their involvement).

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

1) Assign ownership and define the control boundary

• Name a control owner (often Security Awareness lead, GRC, or IR program owner).
• Define the in-scope population (who must participate, by role group).
• Document which systems/business units are covered under the control statement.

Operator tip: auditors challenge “enterprise-wide” claims. Write the scope in the same language as your system boundary and SSP if you have one. ²

2) Build a scenario library tied to your likely incident types

Create a small set of scenarios that reflect your environment and your incident handling expectations. Keep them specific enough to test behaviors.

Example scenario categories (pick what matches your risks):

• Suspicious email with credential harvesting attempt (reporting and escalation).
• Lost or stolen endpoint (timely reporting, remote wipe steps, ticket routing).
• Mis-sent email containing sensitive data (data spill containment and notification path).
• Third-party compromise notification (intake, verification, and internal escalation).
• Privileged account misuse indicator (admin response and evidence preservation).

For each scenario, document:

• Trigger (what the participant sees).
• Expected actions (what “good” looks like).
• Time expectations (qualitative is fine; focus on sequence and correctness).
• Escalation path (who gets notified; what tool/channel).
• Data handling rules (what not to do, such as forwarding sensitive content).

3) Choose exercise formats that qualify as “practical”

AT-2(1) does not force a single format; it requires simulations of events/incidents. Select formats you can run repeatedly and evidence cleanly:

• Simulated phishing/reporting drills (if you track reporting behavior and follow-up coaching).
• Role-based tabletop drills with scripted injects and required decisions/actions.
• Hands-on ticket drills (simulate an incident report entering the service desk workflow).
• ChatOps/phone-tree drills (simulate escalation communications).

Decision rule: if a participant can complete it without taking any action (other than watching/reading), it is probably not “practical” for AT-2(1). ¹

4) Write an implementation procedure (make it repeatable)

Create a short SOP that an auditor can follow:

• How scenarios are selected and approved.
• How exercises are launched (tools, channels, facilitators).
• How participation is captured (LMS export, roster, system logs).
• How results are evaluated (criteria, scoring rubric, pass/fail if used).
• How corrective actions are assigned and tracked.

This is where many teams fail. They run drills, but they cannot show a controlled process.

5) Execute exercises and capture outcomes

Run the exercises with the in-scope population. Capture outcomes that show the simulation happened and that it tested incident response behaviors, such as:

• Who participated and when.
• What actions they took (reported, escalated, opened ticket, followed playbook).
• Common errors (misrouting, delay, incomplete info, unsafe handling).
• Remediation taken (targeted retraining, playbook update, comms update).

6) Close the loop with corrective actions

AT-2(1) becomes materially stronger when exercises drive improvements:

• Update playbooks or runbooks if confusion repeats.
• Adjust reporting mechanisms if people cannot find them.
• Add targeted micro-training for groups with recurring mistakes.
• Feed findings into incident response planning and training content.

7) Map the requirement to evidence artifacts (assessment-ready)

Make the mapping explicit in your control narrative: owner, procedure, cadence, artifacts. If you use Daydream, set AT-2(1) up as a control with a recurring evidence request workflow so rosters, scenarios, and after-action notes are collected consistently rather than reconstructed during an audit.

Required evidence and artifacts to retain

Keep evidence in a form that stands on its own in an exam package:

Core artifacts (expected):

• Practical exercise plan or SOP (how you design/run exercises).
• Scenario scripts/injects and expected response criteria.
• Participation records (rosters, LMS completion exports, facilitator sign-in sheets).
• Exercise results summary (what happened, key findings).
• Corrective action tracker entries and closures (tickets, action log).
• Proof of communications and escalation mechanics tested (screenshots/logs as appropriate).

Nice-to-have artifacts (helps in audits):

• Role mapping (which roles get which scenario types).
• Version history showing scenarios refreshed over time.
• Evidence of management review of results and approvals.

Common exam/audit questions and hangups

Expect assessors to press on these points (and prepare short, direct answers):

1. “Show me an exercise that simulated an incident.” Provide the scenario, roster, and results package. ¹
2. “How do you know people learned the right behavior?” Show evaluation criteria and follow-up remediation for misses.
3. “Is this training role-based?” Show role-to-scenario mapping and privileged-user drills.
4. “How often do you do this?” Answer with your defined cadence and last-run dates; consistency matters more than ambition.
5. “What changed as a result?” Show corrective actions and updated runbooks.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Calling annual CBT “practical exercise”	No simulated event; no action rehearsal	Add drills that require reporting/escalation actions tied to scenarios. 1
Running a tabletop with no artifacts	Cannot prove it occurred	Use a facilitator packet, roster, and after-action notes template every time.
Exercises unrelated to your environment	Looks like checkbox compliance	Tie scenarios to your actual incident categories and escalation paths.
No corrective actions	Training does not improve operations	Track findings as tickets with owners and due dates.
Ignoring third-party pathways	Real incidents often involve third parties	Include at least one scenario that starts with a third-party notification and tests intake/escalation.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so you should treat AT-2(1) primarily as an assessment and operational resilience expectation rather than a standalone enforcement hook.

Operationally, weak practical exercises create predictable failure modes during real incidents: slow reporting, mis-escalation, poor evidence handling, and inconsistent communications. Those failures increase containment time and raise the chance of procedural noncompliance with your own incident handling requirements. In federal and contractor contexts, that can drive adverse assessment outcomes, contract risk, and incident response friction.

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign control owner and document scope and training population.
• Draft the AT-2(1) SOP (scenario selection, execution, evidence).
• Build an initial scenario library with role mapping.
• Create evidence templates: roster, facilitator guide, results summary, corrective action log.

Next 60 days (run and stabilize)

• Run the first two practical exercises (one general-user, one role-specific).
• Capture artifacts end-to-end and store them in your audit repository.
• Open corrective actions and assign owners; schedule follow-up micro-training as needed.

By 90 days (make it repeatable)

• Update scenarios based on findings and repeat a drill to show improvement.
• Finalize the control narrative with explicit evidence references.
• Automate evidence collection and reminders (for example, with Daydream workflows) so each exercise produces the same artifact set without scramble.

Frequently Asked Questions

Does a phishing simulation count for AT-2(1)?

It can, if the exercise simulates an incident pathway and tests required actions (reporting, escalation, safe handling) with recorded outcomes and follow-up. Keep the scenario, participation, and results as evidence. ¹

Do exercises have to include the full incident response team?

No. AT-2(1) is part of literacy training, so many exercises target general users or specific roles. Add IR-team drills when your training program includes those roles and responsibilities. ²

What’s the minimum evidence an auditor will accept?

Provide a scenario script, a dated roster, and a results record showing what participants did and what you changed or assigned afterward. If any one of those is missing, expect a “not implemented” or “no evidence” finding risk. ²

How do we handle contractors and third parties in scope?

If they have access to the system or handle federal data in your environment, include them in role-appropriate exercises or document an equivalent requirement in contracts and verify completion evidence. Treat them as part of the training population if they are part of the operational workflow. ²

Can we run tabletop exercises remotely?

Yes. Remote works well if you keep facilitation tight, use scripted injects, and capture attendance and decisions in a structured record you can retain for audit.

How do we keep exercises from disrupting operations?

Use short, role-targeted drills, coordinate with operational owners, and run “quiet” simulations that test reporting and escalation without touching production. Document boundaries in the facilitator guide.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5