AT-2(5): Advanced Persistent Threat

To meet the at-2(5): advanced persistent threat requirement, you must deliver literacy training specifically about Advanced Persistent Threats (APTs) and be able to prove who received it, what it covered, and that it happens as part of your security awareness program 1. Operationalize it by scoping the audience, defining APT learning objectives, deploying role-aware training, and retaining durable evidence.

Key takeaways:

  • AT-2(5) is a training content requirement: your program must explicitly cover APT concepts 1.
  • Auditors will look for repeatable delivery + proof (curriculum, completion, exceptions), not a one-time slide deck.
  • Treat APT literacy as role-based for high-risk functions (admins, developers, SOC, executives), then document that tailoring.

AT-2(5) sits under the NIST SP 800-53 Awareness and Training family and narrows the general security literacy expectation into a specific topic: Advanced Persistent Threats. For a CCO or GRC lead, the work is less about defining what an APT is and more about turning that definition into a training control that can survive an assessment. That means: a clear control statement, assigned ownership, a training module with measurable learning objectives, and evidence that training reaches the right population on a recurring basis.

Most teams fail AT-2(5) in predictable ways: they run “security awareness” broadly, but the curriculum never explicitly addresses APT tradecraft (phishing-to-lateral movement, credential access, persistence), or they cannot show the module content that was actually delivered. The fix is straightforward. Build a short APT literacy module (or add an APT section to an existing module), map it to roles and systems that handle federal data or support federal information systems, and run it through the same governance and evidence cycle you use for other mandatory trainings.

This page gives requirement-level guidance you can execute quickly, with steps, artifacts, and audit-ready proof points grounded in the control’s text 2.

Regulatory text

Requirement (AT-2(5): Advanced Persistent Threat): “Provide literacy training on the advanced persistent threat.” 1

What the operator must do: Deliver security literacy training content that explicitly covers APTs, assign responsibility for maintaining that content, and maintain evidence that the intended audience completed it as part of your awareness and training program 1.

Plain-English interpretation (what this actually means)

AT-2(5) expects more than generic phishing training. You need a curriculum element that teaches personnel:

  • What “advanced persistent threat” means in practical terms (well-resourced, targeted, patient adversaries).
  • Common APT attack chains (initial access → execution → persistence → privilege escalation → lateral movement → exfiltration/impact).
  • What behaviors APTs exploit (credential reuse, weak MFA enrollment, oversharing, unmanaged endpoints, misconfigurations).
  • What each person should do differently as a result (reporting, verification steps, secure admin behaviors, change control discipline).

“Literacy training” signals comprehension-level content, not deep operator certification. Your SOC will need deeper training elsewhere; AT-2(5) is about baseline organizational understanding, aligned to real threats.

Who it applies to (entity and operational context)

Entity types commonly scoped to AT-2(5):

  • Federal information systems implementing NIST SP 800-53 controls 3.
  • Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually or through program requirements 3.

Operational context (where auditors focus):

  • Systems and business units that process, store, administer, or secure federal information.
  • Teams with privileged access or outsized blast radius (identity admins, system admins, cloud platform engineers, security engineers, incident responders).
  • Personnel who approve sensitive actions (finance approvers, executives, program managers) because APTs often use social engineering against authority paths.

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

1) Define the control implementation in one paragraph

Write an internal control statement that answers: who is trained, what they’re trained on, how training is delivered, how often it occurs (your policy choice), and how completion is tracked.

Practical control statement template:

  • “The organization provides mandatory APT literacy training to the defined workforce population. Training covers APT characteristics, common tactics, reporting requirements, and role-specific scenarios. Completion is tracked in the learning system and exceptions are documented and approved.”

2) Assign ownership and governance

Operationally, AT-2(5) needs a single throat-to-choke:

  • Control owner: Security Awareness lead or GRC Training owner.
  • Content owner: Security team member who can keep content aligned to current tactics.
  • Approver: CISO (or delegate) for content; HR/L&D for delivery mechanics.

If you use Daydream to manage your control system, map AT-2(5) to the control owner, the procedure, and recurring evidence artifacts so the assessment package stays current 1.

3) Scope the audience (don’t default to “everyone” without thought)

Build a simple audience matrix:

  • Baseline: all workforce members with access to corporate systems supporting federal work.
  • Role-based add-ons: privileged users, developers, SOC/IR, executives, third parties with access.

Include third parties where they have network/system access or handle federal data under your responsibility. Your contracts and access governance should align with your training scope.

4) Build or procure APT literacy content with explicit learning objectives

Your module should be short enough to finish, but specific enough to be defensible. Minimum topics most assessors expect to see:

  • APT definition and how it differs from commodity crime.
  • Typical APT lifecycle and persistence concepts.
  • Spearphishing, watering holes, supply chain targeting, credential theft.
  • Identity and access behaviors: MFA fatigue risks, token theft awareness, admin separation.
  • Reporting: what to report, how, and timelines (use your internal standards; avoid numeric promises you can’t meet).

Make it auditable: Put “Advanced Persistent Threat (APT) Literacy” in the module title or section heading. Don’t bury it inside a generic deck.

5) Add role-based scenarios for high-risk functions

Keep the base module consistent, then add short role vignettes:

  • Executives: targeted social engineering, out-of-band verification for sensitive approvals.
  • Admins: persistence indicators, privileged access hygiene, change control, PAM expectations.
  • Developers/DevOps: supply chain risk awareness (malicious packages), secrets handling, CI/CD access.
  • SOC/IR: escalation triggers, threat intel handling (this can reference your internal playbooks).

6) Deliver training and enforce completion

Execution mechanics:

  • Push via LMS with attestation and knowledge checks.
  • Track completions, overdue status, and exceptions (leave, onboarding timing, contractors).
  • Ensure onboarding includes APT literacy for in-scope roles.

7) Retain evidence in an assessment-ready package

Treat evidence as a product:

  • One folder (or GRC system record) per training cycle.
  • Version control for content.
  • Exportable completion proof.

8) Test the control like an auditor would

Run a mini-sample:

  • Pick several users across roles.
  • Produce: completion record, module outline, and policy/procedure mapping.
  • Confirm the module explicitly says “APT” and covers APT concepts.

Required evidence and artifacts to retain

Maintain artifacts that prove design and operating effectiveness:

Design evidence (what you intended):

  • Security awareness and training policy referencing role-based training and required topics (include APT literacy) 3.
  • AT-2(5) procedure/runbook: scope, roles, delivery method, tracking method.
  • Training content: slides, script, video link, module outline, and learning objectives labeled for APT.
  • Version history / change log for content updates.

Operating evidence (what happened):

  • LMS completion report for in-scope users (date completed, module name, pass/attestation).
  • New hire onboarding checklist showing assignment of the APT module.
  • Exception log with approvals (e.g., leave, delayed start, contractor offboarding).
  • Communications: training assignment emails or LMS campaign records.

Assessment convenience artifacts (saves time):

  • Roster of in-scope population and how it was derived (HRIS export + access groups).
  • A mapping sheet connecting AT-2(5) to your training module(s) and evidence locations 1.

Common exam/audit questions and hangups

Auditors and assessors tend to ask:

  • “Show me the exact content that addresses APTs.” (They want the module, not a policy quote.)
  • “Who is required to take it, and how do you know they did?” (Expect population definition + completion proof.)
  • “How do you handle contractors or third parties with access?” (Expect contractual/training requirement or access gating.)
  • “How do you keep the content current?” (Expect an owner and a review/update cadence you can demonstrate.)
  • “What happens when someone doesn’t complete training?” (Expect escalation workflow, not informal chasing.)

Hangup: teams confuse AT-2(5) with incident response training. Keep the boundary clear: this is literacy training about APTs under Awareness and Training, even if you coordinate with IR.

Frequent implementation mistakes (and how to avoid them)

  1. APT content is implied, not explicit.
    Fix: Put “Advanced Persistent Threat” in the module title/section header and learning objectives 1.

  2. No scoping logic.
    Fix: Document in-scope populations (employees, contractors, privileged roles) and the source of truth for the roster.

  3. Evidence is scattered across HR, LMS, and email.
    Fix: Build a single evidence packet per cycle with exports and snapshots.

  4. One-time delivery with no lifecycle.
    Fix: Assign content ownership and document how updates are reviewed and approved. Save the change log.

  5. Third parties are ignored.
    Fix: If third parties have access or handle federal data under your program, require training completion or enforce compensating controls (access restrictions) and document the decision.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions or penalties.

Operationally, the risk is still concrete: APTs target human workflows (approvals, privileged access, software supply chain). If training does not cover these patterns, you increase the chance of credential compromise, unauthorized access persistence, and slow detection. For regulated environments and federal programs, weak training evidence also creates assessment friction: you may have a functioning awareness program but fail the specific enhancement because APT literacy cannot be demonstrated.

A practical 30/60/90-day execution plan

First 30 days (stand up the control)

  • Assign control owner, content owner, and approver.
  • Draft the AT-2(5) control statement and procedure.
  • Identify in-scope populations and establish the roster source.
  • Create or procure an APT literacy module with explicit APT labeling 1.
  • Define the evidence packet format (what you will export/save each cycle).

Next 60 days (deliver and prove operation)

  • Launch the training campaign in the LMS.
  • Run targeted sessions or add-ons for privileged roles and executives.
  • Capture operating evidence: completion exports, exceptions, communications.
  • Perform an internal audit-style sample to confirm you can produce content + completion proof on request.

By 90 days (stabilize and make it repeatable)

  • Formalize review/update workflow for APT content and retain change logs.
  • Integrate training assignment into onboarding and access provisioning for privileged roles.
  • Implement recurring evidence collection (automated exports or scheduled snapshots).
  • If you manage controls in Daydream, connect AT-2(5) to its owner, procedure, and recurring artifacts so audits pull from a single system of record 1.

Frequently Asked Questions

Does AT-2(5) require training for every employee?

The control requires APT literacy training, but you choose the scoped population based on your system context and risk. Many programs train all users with system access, then add deeper role-based material for privileged or high-risk roles.

Can we satisfy AT-2(5) by adding one slide about APTs to our annual security awareness?

You can, if the content genuinely teaches APT literacy and you can prove it was delivered and completed. In practice, assessors respond better to a clearly labeled APT section or module with learning objectives and a completion record 1.

What evidence is usually decisive in an assessment?

Provide the training content (or outline) showing APT coverage plus LMS completion records tied to an in-scope roster. Keep exception handling proof so gaps don’t look like uncontrolled noncompliance.

How should we handle contractors or other third parties with access?

If they access your systems or handle federal data under your responsibility, require training completion via contract terms, onboarding steps, or access gating. If you choose a compensating approach, document it and tie it to access restrictions.

How “technical” does APT training need to be?

“Literacy” suggests comprehension and behavior change, not deep technical certification. Tailor depth by role: general users need recognition and reporting skills; admins and engineers need scenarios tied to privileged access and change control.

We have threat awareness briefings for the SOC. Does that satisfy AT-2(5)?

SOC briefings help, but AT-2(5) is part of the broader awareness and training program and typically expects coverage beyond a small technical group. Keep SOC training as supplementary evidence, and still deliver workforce-appropriate APT literacy content 1.

Footnotes

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

  2. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

  3. NIST SP 800-53 Rev. 5

Frequently Asked Questions

Does AT-2(5) require training for every employee?

The control requires APT literacy training, but you choose the scoped population based on your system context and risk. Many programs train all users with system access, then add deeper role-based material for privileged or high-risk roles.

Can we satisfy AT-2(5) by adding one slide about APTs to our annual security awareness?

You can, if the content genuinely teaches APT literacy and you can prove it was delivered and completed. In practice, assessors respond better to a clearly labeled APT section or module with learning objectives and a completion record (Source: NIST SP 800-53 Rev. 5 OSCAL JSON).

What evidence is usually decisive in an assessment?

Provide the training content (or outline) showing APT coverage plus LMS completion records tied to an in-scope roster. Keep exception handling proof so gaps don’t look like uncontrolled noncompliance.

How should we handle contractors or other third parties with access?

If they access your systems or handle federal data under your responsibility, require training completion via contract terms, onboarding steps, or access gating. If you choose a compensating approach, document it and tie it to access restrictions.

How “technical” does APT training need to be?

“Literacy” suggests comprehension and behavior change, not deep technical certification. Tailor depth by role: general users need recognition and reporting skills; admins and engineers need scenarios tied to privileged access and change control.

We have threat awareness briefings for the SOC. Does that satisfy AT-2(5)?

SOC briefings help, but AT-2(5) is part of the broader awareness and training program and typically expects coverage beyond a small technical group. Keep SOC training as supplementary evidence, and still deliver workforce-appropriate APT literacy content (Source: NIST SP 800-53 Rev. 5 OSCAL JSON).

Operationalize this requirement

Map requirement text to controls, owners, evidence, and review workflows inside Daydream.

See Daydream