03.02.01 Literacy training: requirements and evidence

What 03.02.01 literacy training requires from every system user

When a contract requires NIST SP 800-171 Rev. 3, the first question for a compliance lead is who must be trained. Requirement 03.02.01 answers it: every system user, not only staff with security duties. Those with assigned security roles fall under the sibling requirement 03.02.02, which covers role-based training. Under 03.02.01, the general user community must receive security literacy training at onboarding, at a defined frequency afterward, and after defined events. The content must cover recognizing and reporting indicators of insider threat, social engineering and social mining. Rev. 3 absorbed the separate insider threat requirement from Rev. 2 (3.2.3) into this one, so an organization that kept insider threat as its own module should confirm that it sits inside the literacy program.

The difficulty is that 03.02.01 leaves four organization-defined parameters (ODPs) to the organization. Someone must decide how often refresher training is delivered after initial training, which events trigger a training requirement (for example, a new reporting channel or a change to the CUI handling procedure, offered here only as an illustration), how often the training content is updated, and which events force a content update. NIST does not supply these values. If the federal agency in the contract does not specify them, the nonfederal organization must assign them, and an assessor will check that each ODP has a defined value. Ask the contracting officer whether ODP values have been provided before drafting them.

Evidence has to prove two things: that training was delivered to each user, and that the content was kept current under the parameters the organization set. Keep a dated record of completions for every account, the training curriculum and its version history, the policy and procedure that name the ODP values, and records showing that content was reviewed after the defined events. Learning platforms can produce completion records, but they will not decide the parameters or prove the content is current, so the policy must line up with what the system actually does. The assessment method in SP 800-171A Rev. 3 also includes interviews with the general user community, so staff should be able to describe the reporting path in their own words.

Which users, systems and contractors fall under literacy training

Literacy training under 03.02.01 applies to the people who touch systems holding CUI, not only employees on the payroll. The decisions below set who is in the training population, which accounts are covered by the System Security Plan boundary, and how shared and service accounts are handled, each of which changes the training records an assessor will ask to see.

Every user with an account in scope

03.02.01 is written around system users, so the training population starts with anyone who holds an account on a system that stores, processes or transmits CUI. Employees are the obvious group. Temporary staff, interns and consultants with accounts are equally in scope. Build the list from the identity provider and the directory, not from HR headcount, and reconcile the two each quarter so that a contractor with a live account never falls outside the training record. Ask the assessor how they expect population completeness to be shown.

Third-party administrators with privileged access

Managed service providers, outsourced help desks and vendor support engineers who log in to administer CUI systems are system users for this requirement. Their organization may train them under its own program, but the assessed organization still needs evidence that they received security literacy training covering insider threat, social engineering and reporting. Put the training obligation in the service contract, and collect completion evidence from the provider before granting access. Privileged users may also need role-based training under 03.02.02.

Systems inside the SSP boundary

The training population follows the System Security Plan boundary. Any system that stores, processes or transmits CUI, and any supporting system that can reach it, defines who must be trained. A collaboration tool that receives CUI in a file share, or a ticketing system that holds CUI attachments, pulls its users into scope even if the team using it sits in another department. Review the boundary diagram and the list of connected systems whenever the SSP changes, and update the training roster to match.

Shared and service accounts

Shared and service accounts cannot complete training, so they do not belong on the roster as learners. The work shifts to the people who use them: every individual who logs in to a shared account or triggers a service account's actions must be trained and tracked under their own identity. Document which people have access to each shared account, and treat any unlisted user as a gap. Ask the assessor how they will verify the mapping between shared accounts and the people behind them.

Contractors and subcontractor personnel

Subcontractors whose staff handle CUI in the prime's systems, or whose own systems hold CUI, bring their people into scope. Where the subcontractor runs its own systems, the subcontractor owns training for its users, but the prime should still confirm that training meets the ODP values it has set. Confirm in the subcontract how training evidence will be shared and how often. Contractors with access that ends at a defined date should still complete training before their first access.

Defining ODP values for the population

The frequency and triggering events in 03.02.01 are organization-defined parameters that the organization must set if the federal agency does not. Who counts as a system user affects how these values are applied in practice, for example whether a new hire in a non-CUI role needs training before any CUI system access. Document the population definition, the training timing and the triggering events in one place. Confirm with the contracting agency whether it has assigned any values before writing your own.

How an assessor tests 03.02.01 training and awareness

This table compares what an assessor does for 03.02.01, the evidence they usually ask for, and where organizations tend to fall short. The 11 determination statements and four ODP checks are grouped by test method, so you can see which records to have ready before the assessment starts. The main takeaway is that the ODP values and dated curriculum records often decide the outcome more than the training itself.

Assessment element	How the assessor tests it	Evidence to prepare	Common findings
Training policy and procedures	Examine whether the organization has documented security literacy training and awareness policy and procedures, and whether they cover the training required under this requirement.	Approved training policy, implementing procedures, named owner, and the date of last review.	Policy exists but does not mention insider threat, social engineering or social mining, or no owner is named.
Organization-defined parameters	Check that values are defined for the four ODPs: training frequency after initial training, events that trigger training, content update frequency, and events that trigger content updates.	A written statement of each ODP value, with the approval record and the system security plan reference.	One or more ODP values are blank, vague (for example, "periodically") or inconsistent between policy and practice.
Curriculum content	Examine the training curriculum to confirm it covers recognizing and reporting insider threat indicators, social engineering and social mining.	Current curriculum or course outline, with each topic mapped to the policy statement it supports.	Curriculum covers phishing only, with no coverage of insider threat or social mining.
Initial training at onboarding	Interview training staff and examine records to confirm that system users receive security literacy training as part of initial training.	Onboarding checklist, completion records for recent hires, and the system access grant date for each.	Access is granted before training is completed, or onboarding records do not show completion dates.
Recurring and event-driven training	Examine records against the defined frequency and triggering events, and interview users about what training they received after system changes.	Training completion logs by user, dated reminders, and records of training triggered by changes or incidents.	Records show training once at onboarding and nothing afterwards, even though the organization's own frequency requires refresh.
Content update records	Examine the update history of the curriculum against the defined content update frequency and triggering events.	Version history of training materials with dated revisions and the reason for each change.	Curriculum files have no dates or version numbers, so the assessor cannot confirm updates occurred on schedule.
Interviews with the user community	Interview a sample of general system users to confirm they recognize insider threat, social engineering and social mining, and know how to report them.	Attendance or completion evidence for interviewees and a reporting channel the users can name.	Users cannot describe the reporting path, or staff are trained but cannot recall the content.
Test of training mechanisms	Test the learning management or tracking mechanism to confirm it records training, completion and content versions as the policy states.	Screenshots or exports from the learning platform, plus configuration showing completion rules and retention settings.	Completion tracking is set to mark activities complete on view only, so the record does not show that the content was understood.

Setting the four ODPs and building the training program in order

This sequence turns the four organization-defined parameters of 03.02.01 into written decisions, then builds the curriculum, delivery and tracking so an assessor can trace every setting to a record. Each step closes with an artifact you can hand to an assessor.

Confirm which ODP values the agency sets
Start by asking the federal agency or prime contractor, in writing, whether it has specified values for the four ODPs that 03.02.01 requires: the post-initial-training frequency, the events that trigger training, the content update frequency and the events that trigger content updates. NIST does not assign these values, and under NIST's guidance the nonfederal organization must assign any value the agency leaves open. Record each parameter as either agency-specified (with the contract clause or letter that states it) or organization-assigned. The output is a short ODP inventory with a source column, reviewed by the compliance lead and the contracting owner.
Set the post-onboarding training frequency
For any ODP the organization must assign, choose a recurring training frequency for system users after initial training and document the reasoning. Tie the choice to the risk of the CUI environment, the rate of staff turnover and how often the threat landscape changes for your sector, and make sure the value is stated as a specific interval rather than a phrase such as periodically. Have the CISO or accountable executive approve it. The output is a signed ODP decision record with the frequency, rationale and approver, which the assessor will compare against the system security plan.
Define the events that trigger training
Write the list of events that require security literacy training for system users outside the regular cycle. Typical candidates include onboarding of new users, changes to the system or its CUI handling procedures, a confirmed phishing or social engineering incident, a change in the threat picture that the organization has documented, and the adoption of a new collaboration tool. Keep each event observable, so that someone can show that the trigger fired and that training followed. The output is the event list added to the ODP decision record, with an owner for detecting each event.
Set the content update frequency and events
Set how often the security literacy training content is reviewed and updated, and list the events that force an earlier update, such as a change to the system security plan, a new reporting obligation, a material change in the CUI environment or a lesson from an incident. The content update parameters are separate from the delivery parameters, so an assessor will look for both. Assign an owner who signs off each content revision. The output is the completed four-parameter ODP record, with each value marked as agency-specified or organization-assigned.
Build the curriculum and its coverage map
Write the curriculum so that it covers recognizing and reporting indicators of insider threat, social engineering and social mining, along with the organization's own handling rules for CUI. Map each module to the requirement text and to the reporting path that staff must use, which should match the incident response procedures in 03.06. Where your organization uses an outside content provider or a learning platform, confirm that it can deliver the required topics and update on your schedule. The output is a curriculum document with a coverage map that links each topic to 03.02.01 and to the version and date of the content.
Deploy delivery and completion tracking
Configure the learning platform so that training assignments, reminders and completion records are generated automatically. In a self-hosted Moodle deployment, for example, you can set activity completion conditions so that an activity is marked complete when the learner views it, receives a grade, or ticks it manually, and you should choose the condition that proves the learner actually engaged with the material. Confirm that onboarding and event-triggered assignments fire from the ODP record rather than from memory. Test the workflow with a pilot group. The output is a first completion report that shows the course version, assigned users, completion dates and any overdue records.
Retain evidence for the assessor
Store the ODP decision record, the curriculum and coverage map, the content revision history, the assignment rules and the completion reports in a location that the assessor can access during the assessment. Check that the policy and procedures for security literacy training and awareness reference the ODP record, so that the examine and interview steps in SP 800-171A lead to the same answers. Ask an internal reviewer to walk through the chain from ODP value to completion record. The output is a complete evidence package and a dated internal review note.

Why the insider threat requirement now sits inside literacy training

In Rev. 2, insider threat awareness was a requirement of its own, 3.2.3, separate from general security awareness. Rev. 3 withdrew that requirement and folded it into 03.02.01 Literacy training and awareness, so the insider threat content now has to be provable inside the general security literacy curriculum. An assessor reviewing 03.02.01 will look for that content in the training materials themselves, not for a standalone insider threat course. Before you plan any changes, pull the current curriculum and map each Rev. 2 insider threat topic to a specific module, lesson or quiz item. Any topic without a home in the curriculum is a gap to close before assessment.

The content work centers on three things the curriculum must teach users to recognize and report: indicators of insider threat, social engineering, and social mining. Insider threat indicators are behaviors and access patterns that users are taught to notice and escalate, such as unusual requests for CUI outside someone's role. Social engineering covers manipulation attempts such as pretexting or urgent requests that bypass procedure. Social mining covers the collection of information about staff, projects or systems from public sources, which often precedes the other two. The reporting path matters as much as recognition: users need to know the channel, the contact and what to include, and the curriculum should show that path with the same clarity as the recognition material. Confirm that the reporting channel named in training matches the one in your incident response procedures.

NIST's Rev. 2 to Rev. 3 change analysis classifies the change from 3.2.1 to 03.02.01 as significant, meaning the requirement asks for more detail and foundational tasks than before, so an existing awareness program written for Rev. 2 is unlikely to pass unchanged. The compliance picture adds a timing issue. CMMC Level 2 still assesses the Rev. 2 requirements, and in that framework insider threat sits in its own practice, AT.L2-3.2.3, separate from AT.L2-3.2.1. A single training record may therefore need to answer to two numbering schemes. Ask your assessor or contracting officer which version governs your contract before you restructure records, and keep a crosswalk showing where each Rev. 2 insider threat topic now lives in the Rev. 3 curriculum.

Evidence that passes 03.02.01 and how to keep it current

An assessor testing 03.02.01 will look for proof that training happened, that its content matches the organization's own defined values, and that the content changed when triggering events occurred. The six artifacts below connect those three checks, and each one needs an owner who signs off on it before the next assessment window.

Training and awareness policy and procedures

This is the written policy and the procedures that state who receives security literacy training, when, and how completion is recorded. An assessor compares these documents with what the organization actually does, so the procedures must name the same frequency, events and roles that appear in the ODP decision record. Review the documents at least once a year and after any change to the system boundary or the workforce model. The information security officer should approve each version, and the version history should show every revision date.

Curriculum with version and date

The curriculum shows what users are taught about insider threat, social engineering and social mining, and it must carry a version number and an effective date. Assessors use it to confirm that the content covers the indicators the organization has defined for recognizing and reporting these risks. Store each version in a controlled repository so that a training record can be matched to the exact content a user saw. The training owner signs off on each version, and the security lead reviews it whenever the threat picture or the system changes.

Completion records per user

Completion records show that each system user received the training at onboarding and at the frequency the organization set. Export records from the learning platform with the user identifier, course version, completion date and score, so an assessor can sample individuals and trace each one. Check for gaps by comparing active accounts against completions every reporting period, and treat users who never completed the course as an open finding. The learning administrator produces the export, and the human resources or security manager reviews the exceptions.

ODP decision record with values set

NIST does not assign values to organization-defined parameters, so this record documents the frequency for periodic training, the events that trigger training, the frequency for content updates and the events that require a content update. Each value needs a stated rationale tied to the risk assessment. If a federal contract or agreement specifies values, record those and the source document. The record should show the approval date and the approver, and the security lead should confirm the values again whenever the risk assessment or contract changes.

Content update logs tied to triggering events

Content update logs show that the organization revised training when a defined event occurred, such as a phishing campaign, a new attack technique, a system change or a confirmed incident. Each log entry should name the triggering event, the date it was detected, the date the content changed and the new curriculum version. Assessors look for this chain of cause and response, so a log that records only routine annual reviews is weak evidence. The training owner maintains the log, and the security lead reviews it at each quarterly security meeting.

Insider threat reporting cases and exercises

Reporting cases and exercises show that users can recognize and report insider threat indicators and social engineering attempts in practice. Keep anonymized examples of reports received, how they were triaged and what training followed, along with records of simulated phishing or social mining exercises and the results. Handle personal data carefully and limit access to these records. The security operations lead prepares the summary, and the chief information security officer signs off on the set of exercises and the lessons drawn from them.

What literacy training costs to meet in money and effort

This table breaks down the cost components behind meeting 03.02.01, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, because no supplied figures set prices or durations for this requirement. The main takeaway is that recurring costs tied to event triggers and content change rate usually matter more than the first build.

Cost component	One-time or recurring	What drives it up	How to keep it down
Curriculum development or licensed content	One-time build, recurring updates	Number of roles and topics, depth on insider threat and social mining, number of languages	Reuse modular content, license only where the content is generic, scope the first release to the user population
Learning platform licenses or self-hosted hosting	Recurring	Active user count, number of course environments, reporting features required	Use an open-source LMS such as Moodle inside your own infrastructure, confirm license terms and hosting capacity before sizing
Engineering time to integrate completion tracking	One-time, with periodic rework after upgrades	Number of completion conditions, links to HR and identity systems, custom reporting to the system security plan	Use native completion features where they meet the requirement, document the completion rules once, limit custom code
Instructor or content owner time	Recurring	Frequency of training after onboarding, number of defined trigger events, staff turnover	Automate reminders for periodic refreshers, batch event-driven training, assign a named content owner
Content review and update effort	Recurring	Rate of system, threat and policy change, number of defined content update events	Set a fixed review schedule, tie updates to change control records, track the defined update frequency in one place
Evidence upkeep	Recurring	Number of user records, frequency of completion reports, number of systems in scope	Export completion records on a fixed cadence, keep policy, curriculum versions and completion logs in one repository
External review of the curriculum	Optional, per review cycle	Scope of threat content, need for independent sign-off, number of revisions	Ask for review of the defined frequency and triggers first, limit outside review to the content that changed
Auditor sampling time	Recurring, per assessment	Number of users sampled, quality of completion records, gaps between ODP values and practice	Confirm that ODP values are assigned and documented before the assessment, keep sampled records easy to retrieve

How Moodle can record literacy training completion

Moodle is a GPL-3.0-or-later learning platform that can host the security literacy curriculum and keep a per-learner record of what was completed. The cards below cover the completion conditions that matter for 03.02.01, the difference between viewing and proving comprehension, and the settings an assessor will ask about in your own deployment.

Choose completion conditions per activity

Moodle's activity completion marks an activity complete for each learner when they view it, when they receive a grade from it, or when they tick it manually, depending on the conditions set for that activity. For 03.02.01, decide the condition for each module before launch and record it in the curriculum documentation. Set the condition in the activity settings, not in a separate spreadsheet, so the completion record and the stated rule cannot drift apart. Confirm the options available in your Moodle version.

Grade-based proof of comprehension

View-based completion shows that a learner opened a page, not that they understood it. For the insider threat and social engineering modules, use a graded quiz or assessment so completion depends on a passing grade. A learner who fails can retake the activity, and the record shows the attempt history. This is the evidence an assessor will look for when testing whether training covers recognizing and reporting these indicators.

Reporting exports for assessors

Assessors will ask who completed which module and when. Build a standard report that lists each user, each activity, the completion state, the grade and the completion date, and run it on a schedule. Confirm in your own deployment which reports and export formats are available, and test that a report can be generated for a past period. Keep the exports in the same evidence store as your policy and curriculum documents.

Versioning training content

03.02.01 requires that training content be updated at a defined frequency and after defined events. Moodle does not replace a change log for the curriculum, so record each content revision with its date, the trigger that caused it and the users who were retrained. Keep prior versions available so you can show which content a learner saw at the time of completion. Confirm how your deployment handles course backups and restores before relying on them for this record.

Self-hosting in the client environment

Completion records describe individual people, so decide where the Moodle instance runs before loading any data. Hosting it in your own cloud account or data center keeps learner records, grades and reports under your access controls and retention rules. Confirm the database backup schedule, the log retention settings and who can export completion data. These settings determine whether the evidence still exists when an assessor asks for it.

Who owns the training, what partners can take, and where the assessor stops

Your organization owns requirement 03.02.01 in full. The requirement is met only when the organization's own people have made the decisions it depends on and can show that those decisions were carried out. A partner can draft material, but the accountable owner, usually the CISO or a named security lead, must approve what the training says and how often it runs. The organization is also responsible for how it responds to what the training surfaces, because a report of suspected social engineering or insider behavior is only useful if someone acts on it.

Policy and procedures: Approve the security literacy training and awareness policy and the implementation procedures, and assign who runs them.
Organization-defined parameters: Set the values for the training frequency after initial training, the events that trigger training, the content update frequency and the events that trigger content updates. NIST does not supply these values, so your organization must assign them, or a federal customer must specify them.
Content approval: Review and sign off on the course material covering insider threat, social engineering and social mining, so it reflects your actual threats and reporting channels.
Reporting decisions: Decide who receives reports of suspected insider threat or social engineering and what action follows.

Confirm with your contracting officer or contract documents whether any ODP values are already specified before you set your own.

Where literacy training programs fall short at assessment

Assessors testing 03.02.01 rarely fail a program for lacking a training course. They find the gaps in the parameters, records and coverage around the course. Each card below names one gap, why an assessor will test it, and the closing action that addresses it.

Organization-defined parameters never set

Rev. 3 leaves four parameters for the organization to define: the refresher frequency, the events that trigger training, the content update frequency and the events that trigger content updates. If a federal agency has not supplied values, the nonfederal organization must assign them. Many programs run training without writing these values down, so the assessor finds no defined frequency to test against. Set and document every value in the policy before the assessment begins, and confirm with the contracting agency whether it has specified any values.

Completion that counts only page views

A learner who opens a slide deck has not shown they understood it. Some learning platforms mark an activity complete when the user views it, when a grade is received or when the user ticks a box, depending on how each activity is configured. Assessors will ask which condition the program relies on and whether it proves the user reviewed the material. Require a graded knowledge check on insider threat and social engineering, and set completion so it depends on that check rather than a page view.

No trigger for content updates

The requirement expects training content to change when defined events occur, such as a new phishing campaign, a reported incident or a change to the system. Programs often update content only once a year, so the course describes threats that no longer match what users see. Assessors will look for a dated change log and a link between each threat intelligence source and a content revision. Write the triggering events into the procedure and keep a record of each content revision with its date and reason.

Insider threat missing from the curriculum

Rev. 3 folded the Rev. 2 insider threat requirement into 03.02.01, so the literacy curriculum must cover how users recognize and report indicators of insider threat, along with social engineering and social mining. Programs that still treat insider threat as a separate awareness topic, or drop it when they rewrite the course, leave a gap an assessor will find by reading the curriculum. Map each required topic to a lesson and a test question so the assessor can trace coverage directly.

Contractors and service accounts excluded

Training that reaches only employees misses the general system user community the requirement covers. Contractors with system access, and the people who own service accounts and shared credentials, often sit outside the learning platform. Assessors interview users from this community and ask whether they received the training before access was granted. Enroll contractors and named service-account owners in the same curriculum and tie their access to completion.

Records without content versions

An assessor may ask which version of the course a specific user completed, and whether that version was current on the date of the training. If the learning system overwrites content in place and keeps only completion dates, the program cannot answer. This matters most after a content update triggered by an event. Retain the content version, completion timestamp and user identifier for each completion and keep them for the period the assessor will sample.

What buyers ask about 03.02.01 training cost, effort and ownership

How much effort does it take to meet 03.02.01 in-house?

The effort depends less on the requirement itself than on how many people use your systems, how often your threat picture changes, and whether you already run a learning platform. The requirement asks for security literacy training at onboarding, at a frequency you define, after events you define, and for content that is updated on a schedule you define. Each of those choices is an organization-defined parameter (ODP) that you must set, because NIST does not assign values. Expect in-house effort to cover writing the curriculum, setting the ODPs, delivering and tracking completions, handling training for contractors and temporary staff, and refreshing content after incidents or system changes. Ask your team to estimate those tasks separately so the total is traceable.

What drives the cost of 03.02.01 training?

Four variables drive most of the cost: the number of system users in scope, the number of separate training tracks you need, how often you must deliver and refresh content, and how much evidence your assessor will expect you to produce. A small user population with one annual module costs far less to run than a large workforce with insider threat, social engineering and social mining modules that must be refreshed after defined events. Costs also rise when training records are scattered across HR, IT and email tools. Ask any provider to break its quote into curriculum design, platform setup, content maintenance, evidence preparation and ongoing delivery, so you can see which items recur.

Can our own staff run 03.02.01 training without outside help?

Yes, many organizations run this requirement with their own people, provided they own the policy, the ODP decisions and the sign-off on content. What usually goes wrong is not delivery but maintenance: nobody is assigned to update content after a defined event, or completion records are not kept in a form an assessor can examine. Decide early which parts you will keep in-house, such as policy and approval of content, and which you may hand to a partner, such as platform setup or evidence packaging. An implementation partner prepares systems and evidence, but your organization remains responsible for its controls and for the training it delivers.

How long does 03.02.01 work take, and what should the timing include?

No duration for this work is supplied here, so treat any single number you hear with caution. DeployOpen's engagements are fixed-scope, which means scope, deliverables and timelines are agreed in writing before work starts. Ask for a timeline that lists each milestone: ODP decisions, curriculum build, platform configuration, pilot delivery, first full rollout and evidence handoff. Also ask what depends on your side, such as sign-off turnaround and access to your learning or identity systems. A timeline without named dependencies is hard to check against your assessment date.

What does the work need from our staff?

Plan for time from several roles, not just the security team. Security or compliance staff need to set the ODPs and approve content. HR needs to confirm onboarding triggers and provide accurate user lists. Managers or training owners need to confirm that required modules are assigned and completed. System administrators need to supply access to the learning platform and identity provider so completions can be tied to user accounts. Legal or privacy staff may need to review any content that describes monitoring. Name a single owner for each of these tasks in the written scope so that delays are visible early.

Can a partner prepare the evidence for 03.02.01?

A partner can prepare the systems and the evidence an assessor will examine, including the training policy and procedures, the curriculum, the ODP decisions, delivery and completion records, and records of content updates. A partner cannot issue the assessment result. The assessment itself is run by the assessor or the body that your contract names, and the organization owns the controls being assessed. Ask any provider to list each evidence item it will produce, who approves it, and where it will be stored, and confirm that the list matches what your assessor has said it expects.

Will an assessor accept training records from a self-hosted learning platform?

Assessors generally test whether the records are complete, accurate, traceable to named users and protected from unauthorized change, not whether the platform is hosted by a vendor. Self-hosted open-source platforms such as Moodle can produce completion records, but you must confirm how completion is defined in your configuration. Moodle's activity completion marks an activity complete when a learner views it, receives a grade from it, or ticks it manually, depending on the conditions you set, so the completion rule must match the training you claim was delivered. Confirm the rule, the retention period and the access controls with your assessor before you rely on the records.

How DeployOpen works on this

DeployOpen helps organizations prepare the literacy training program, its content and its records for 03.02.01 so they can show an assessor how users are trained at onboarding, on a defined frequency, after defined events, and on insider threat and social engineering. The organization owns the requirement and its training decisions, and an independent assessor reaches the conclusion.

How we scope

Confirm which system users and user groups fall under the CUI system boundary for the training record.
Record the four organization-defined parameters: training frequency, training trigger events, content update frequency and content update triggers.
Agree in writing which parts of the program DeployOpen will build, document or test, under a fixed-scope engagement.

How we build

Prepare a security literacy curriculum covering insider threat, social engineering and social mining indicators and how to report them.
Configure the learning platform to deliver, track and retain completion records for each user and each training event.
Document the training policy, procedures and content update process so each examine and interview point has a matching artifact.

How we hand over

Deliver a mapping of each 03.02.01 determination statement to the artifact, log or interview answer that supports it.
Hand over the curriculum, completion reports and content revision history in formats the organization can maintain.
Walk the organization's responsible staff through the evidence set so they can answer an assessor's questions directly.

How we support

Ongoing support and periodic content reviews are available as a retainer, separate from the initial fixed-scope work.
Update the curriculum and records when the organization changes its ODP values or when a new insider threat event requires it.
Confirm with the organization's assessor and the written scope which evidence formats they will accept before the engagement closes.