AT-2(6): Cyber Threat Environment

The at-2(6): cyber threat environment requirement is a focused enhancement under NIST SP 800-53 awareness and training controls. For a Compliance Officer, CCO, or GRC lead, the quickest path to “audit-ready” is to treat AT-2(6) as a small, well-defined training product with clear ownership, scope, and recurring evidence.

Most security awareness programs cover baseline topics (passwords, phishing, reporting). AT-2(6) is narrower and more operational: you must teach personnel what the current cyber threat environment looks like for your organization. That means threat actors relevant to your sector, common initial access methods, social engineering patterns, ransomware/extortion realities, cloud identity abuse, supply chain compromise, and the specific “what to do” actions expected from your staff.

This page gives requirement-level guidance you can implement quickly: who needs the training, how to build and run it, what artifacts to retain, and what examiners commonly challenge. The goal is simple: show that your organization can explain the threat environment, train to it, and prove it happened.

Regulatory text

Requirement (excerpt): “Provide literacy training on the cyber threat environment; and” ¹

What the operator must do: You must run security literacy training that explicitly covers the cyber threat environment relevant to your organization and roles. The training must be more than general security awareness; it must help learners understand prevalent threats and how those threats show up in their daily work. The control also implies you keep it current enough to remain credible during assessment ².

Plain-English interpretation (what AT-2(6) is asking for)

AT-2(6) expects you to:

1. Define what “cyber threat environment” means for your context (your systems, data, users, and third parties).
2. Teach personnel the threat reality they actually face (not a generic slide deck).
3. Make the training repeatable (owned, scheduled, tracked).
4. Prove delivery and maintenance (evidence that stands up in an audit).

If your training content cannot answer “What threats are we seeing, how do they target us, and what should staff do differently tomorrow?” you will struggle to defend AT-2(6).

Who it applies to (entity and operational context)

AT-2(6) commonly appears in NIST SP 800-53 control sets used by:

• Federal information systems, including agencies and system owners operating under NIST SP 800-53 baselines ³.
• Contractor systems handling federal data, where NIST SP 800-53 is flowed down via contract, ATO boundary, or overlay requirements ³.

Operationally, it applies to:

• All personnel with access to the system boundary (employees, temps, interns).
• Privileged and sensitive roles (admins, developers, SRE/IT ops, SOC analysts, finance/AP, HR).
• Third parties who access your systems or handle your data, where your agreements require training or your access governance requires it.

Scope decisions should be documented. If you exclude groups (for example, certain third parties), write down the rationale and compensating controls.

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

1) Assign ownership and define training objectives

• Assign a control owner (often Security Awareness lead, GRC, or Security Operations).
• Assign a content owner (often Threat Intel, SOC, or Security Engineering).
• Write 3–6 training objectives tied to real outcomes, such as:
  • Identify common initial access vectors used against your environment.
  • Recognize current social engineering patterns (QR codes, MFA fatigue, helpdesk impersonation).
  • Apply your reporting path and escalation expectations.

Execution tip: Put this in your control narrative so an assessor can see who runs AT-2(6) and how updates happen.

2) Define “your cyber threat environment” in one page

Create a short “Threat Environment Summary” used as the source-of-truth for the module:

• Primary threat actors relevant to you (criminal groups, insiders, opportunistic actors).
• Common tactics you expect (credential theft, business email compromise, ransomware, supply chain compromise).
• High-risk assets and workflows (identity provider, email, endpoints, code repos, payment flows).
• The actions you expect from personnel (verify requests, report, don’t bypass controls).

This does not need to be a classified intel product. It needs to be auditable and tied to your environment.

3) Build a training module that is role-aware

Create a baseline module plus short role add-ons:

Baseline module (all users)

• What the cyber threat environment is and why it targets your org
• Common attack paths (email, SMS, collaboration tools, helpdesk, OAuth consent)
• How to spot and report suspicious activity
• Common mistakes attackers exploit (credential reuse, shadow IT, bypassing MFA prompts)

Role add-ons (examples)

• IT/helpdesk: verification scripts, account recovery abuse patterns, MFA reset social engineering
• Developers: dependency confusion, secrets in repos, CI/CD compromise patterns
• Finance: invoice fraud, wire change requests, executive impersonation controls
• Executives: targeted spearphishing, travel scams, delegated access risks

Practical standard: If you cannot support role add-ons immediately, start with baseline training and document a roadmap for privileged roles.

4) Set cadence and triggers for updates

AT-2(6) is easiest to defend when training updates are tied to triggers:

• Material changes in your environment (new identity provider, major SaaS rollout)
• Notable incidents (internal event or relevant peer event)
• New threat intel relevant to your sector or control weaknesses

Document the triggers and the person responsible for deciding updates. Examiners will look for a living program, not a one-time assignment.

5) Deliver, track, and enforce completion

• Use your LMS, HRIS, or GRC tool to assign training to in-scope users.
• Track completions, overdue users, and exceptions.
• Define escalation for non-completion (manager notification, access restriction for privileged roles, or documented exception).

Third party note: If third parties are in scope, decide whether you will (a) train them directly, (b) accept equivalent training attestations, or (c) restrict access until they meet prerequisites. Document the approach.

6) Connect AT-2(6) to your broader control system

AT-2(6) should not float alone. Cross-reference in your control narrative:

• Incident reporting expectations and channels
• Acceptable use and access control policies
• Phishing reporting procedures and mailbox/queue
• Any threat intel function you have (even if lightweight)

This reduces audit friction because the assessor can see where “threat environment” content comes from and how users are expected to respond.

Required evidence and artifacts to retain (audit-ready checklist)

Keep evidence in a single folder or GRC record tied to at-2(6): cyber threat environment requirement:

Program governance

• Control narrative: scope, owners, cadence, update triggers, exception process
• Training plan and audience matrix (roles mapped to modules)

Training content

• Current training deck/video/module export
• Role add-on content (if applicable)
• Version history or change log (what changed, when, who approved)

Delivery and completion

• LMS assignment report
• Completion reports (by population, by role, and for privileged roles)
• Evidence of follow-up for non-completion (tickets, emails, manager escalations)

Maintenance

• Annual (or scheduled) review record
• Incident-driven update record (if training was updated after an event)

Quality control

• Knowledge checks or quiz questions and pass/fail criteria (if used)
• Feedback loop (survey results or improvement tickets)

Common exam/audit questions and hangups

Expect these questions:

1. “Show me the training materials specifically about the cyber threat environment.”
   Hangup: teams show generic awareness training without threat-environment content.

2. “How do you decide what goes into this module?”
   Hangup: no documented source (threat intel, incidents, risk assessment inputs).

3. “Who is required to take it, and how do you handle third parties?”
   Hangup: unclear scope for contractors, MSPs, or SaaS admins.

4. “How do you keep it current?”
   Hangup: no review cadence or update triggers.

5. “Prove completion.”
   Hangup: screenshots without user-level reports, or reports that don’t match in-scope headcount.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Treating AT-2(6) as “annual phishing training”	“Cyber threat environment” is broader and should reflect current threats	Add threat actor tactics, real attack paths, and role actions; keep a threat summary page
No role differentiation	Privileged and high-risk business roles face different threats	Add short role modules for admins, devs, finance, executives
No update mechanism	Stale content undermines “threat environment” literacy	Define triggers and record reviews/changes
Weak evidence	Assessors test operation, not intent	Centralize artifacts: content versions + LMS exports + exception records
Third party access unmanaged	Third parties often have sensitive access	Put training/attestation into onboarding for third party access requests

Risk implications (what goes wrong if you under-implement)

Poor AT-2(6) implementation increases the likelihood of preventable incidents rooted in human behavior: credential compromise, social engineering, helpdesk takeover, and mishandled incident reporting. From a governance view, the biggest risk is assessment failure due to missing evidence: you may have trained people informally, but you cannot prove it under audit.

Practical 30/60/90-day execution plan

Use this as an execution pattern, then set your own internal dates.

First 30 days (stand up the minimum viable control)

• Assign control owner and content owner.
• Publish the one-page Threat Environment Summary.
• Draft baseline training module content and approval workflow.
• Define in-scope populations (employees, contractors, third parties with access).
• Decide tracking system of record (LMS/HRIS/GRC) and reporting format.

Days 31–60 (roll out and harden evidence)

• Launch baseline module to all in-scope users.
• Add role add-ons for at least privileged users and finance/helpdesk if applicable.
• Implement escalation for non-completion and document exceptions.
• Build an evidence pack folder with: module content, version, LMS exports, audience matrix.

Days 61–90 (make it durable and assessment-ready)

• Run a review and capture the review record (even if no changes).
• Tabletop a “threat trend update” process with SOC/threat intel input and document it.
• Validate population accuracy (new hires, transfers, terminated users).
• If you use Daydream, map AT-2(6) to a control owner, implementation procedure, and recurring evidence artifacts so collection becomes routine instead of a scramble before assessments ¹.

Frequently Asked Questions

Does AT-2(6) require a separate training from annual security awareness?

It can be a separate module or a distinct section within your annual training, but it must clearly address the cyber threat environment. The key is that an assessor can point to content and say, “This is the threat-environment literacy component” ¹.

What counts as “cyber threat environment” content in practice?

Content that explains relevant threat actors and common tactics against your organization, plus the specific actions users must take (verify, report, escalate). Generic “don’t click links” guidance without context is usually thin for AT-2(6).

Do third parties have to take the training?

If third parties have access to your systems or handle your federal data, include them in scope or require equivalent attestation, then document your decision. Auditors mainly care that your scope is deliberate and enforced.

How current does the training need to be?

The control text does not prescribe a specific refresh interval. Define your review cadence and update triggers, then keep evidence that reviews and updates occur ¹.

What’s the minimum evidence to keep if our LMS is limited?

Keep the dated training content, a roster of assigned users, completion acknowledgments (exports or signed attestations), and an exception log. If reporting is manual, document how you validate the roster matches actual access populations.

How do we prove the training is “role-based” if we can’t build many modules?

Start with one baseline module, then add targeted guidance for privileged roles in a short addendum or briefing deck. Keep a role-to-content matrix so you can show the intent and the current state during audit.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5