03.06.04 Incident response training

Requirement 03.06.04 asks nonfederal organizations to train system users on incident response duties that match their roles, on defined timing, after system changes, and with content kept current. This page explains what an assessor checks and what evidence passes.

On this page

What 03.06.04 incident response training asks for and why it fails review

Your contract requires NIST SP 800-171 Rev. 3, and an assessor will ask you to show that people who respond to incidents have been trained for the job they actually do. 03.06.04 requires incident response training matched to each user's role, delivered within a defined time after someone takes on an incident response role or gains system access, repeated at a defined frequency, and provided again after relevant system changes. The training content must also be reviewed and updated at a defined frequency and after defined events. 03.06.04 is new in Rev. 3. NIST maps no Rev. 2 requirement to it, so Rev. 2 assessments and CMMC Level 2, which assesses the 110 Rev. 2 requirements, have no matching requirement ID to point to. Confirm which revision your contract cites before you plan the evidence.

The requirement depends on four organization-defined parameters: the time period for initial training, the frequency of refresher training, the events that trigger a content review, and the frequency of routine content review. NIST does not set these values. If your federal agency does not specify them, you must assign them yourself and write them down, because an assessor will test your stated values against your records. Choose values you can actually meet. A two-week onboarding window that nobody tracks fails on the first sample.

Most organizations fail this review for one reason: they point to a generic annual awareness course and call it incident response training. Awareness content tells staff to report suspicious email. It does not teach the on-call engineer how to preserve volatile evidence, or the legal contact when to escalate a possible CUI incident. Assessors look for curriculum and materials tied to roles, plus completion records showing who was trained, when, and against which version of the content. Your learning platform can produce those records if you configure role-specific courses and completion conditions, for example through Moodle's activity completion, which marks an activity complete when a learner views it, receives a grade, or ticks it. Confirm that the completion rule matches your evidence standard, because a view alone may not prove the person learned the duty.

Which users and roles fall under incident response training in scope

Under 03.06.04, training has to match what each person does during an incident, so the scope starts with a role inventory rather than a headcount. The cards below cover the groups assessors usually expect to see, plus the boundary and access decisions that change how much training work follows.

System administrators and engineers

Administrators who build, patch and run systems inside the CUI boundary are often the first responders who isolate hosts, preserve logs and rebuild systems. Their training should cover the containment and evidence steps in your incident response plan for the platforms they operate, such as directory services, firewalls and hypervisors. Check that the curriculum names the specific systems and commands used in your environment, not only general concepts.

Security operations staff

Analysts who triage alerts, open cases and make escalation decisions need training that matches the tools and reporting clocks they actually use. Confirm that the training covers how an alert becomes a reportable incident, how evidence is logged and how case records are kept. Include anyone who covers the queue on nights and weekends, since they are the people most likely to act before a trainer is available.

Help desk and general users with reporting duties

Help desk staff and ordinary users rarely contain incidents, but they are often the first to notice phishing, lost media or unusual system behavior. Their training should explain what to report, to whom and through which channel, and what to avoid doing, such as powering down a machine or forwarding suspicious files. Ask whether the training is part of onboarding for every account that can reach a CUI system, not only for staff in security roles.

Managers and decision makers

Managers and executives approve containment actions, customer or government notifications and public statements during an incident. Their training is usually shorter but must cover who holds decision authority, how quickly decisions are needed and what information they should expect from the response team. A tabletop exercise is a practical way to show that this group knows its part, and the record of attendance is evidence an assessor can examine.

Third-party staff who operate CUI systems

Managed service providers, cloud operators and subcontractors who administer CUI systems also hold incident response duties, even though they are not your employees. Decide whether their staff are in the training scope, then confirm the contract requires them to complete training and provide records. Make sure their reporting path back to your team is defined and tested before an incident occurs.

Scope boundary and access triggers

Decide whether the training population follows the CUI enclave boundary or the wider network, because that choice determines how many people must be trained. Define the time window for initial training after a role change or new access, and record which events, such as a new system or a major configuration change, require refresher training. Keeping an access and role change log lets you show that the triggers actually fired.

How an assessor tests incident response training

This table breaks down how SP 800-171A Rev. 3 assesses 03.06.04 across its determination statements, ODP checks, examine objects and interview objects. Read each row as a question the assessor will ask and the artifact or person that answers it.

Assessment elementWhat the assessor checksEvidence to prepare
Determination statements (7)Training is given to users consistent with their roles, within the defined time, after system changes and at the defined frequency, with content reviewed on the defined schedule and after defined eventsTraining records per role, dated completion logs, change-triggered training records, content review logs
ODP definition checks (4)Each of the four organization-defined parameters has an assigned value: the time to train, the refresher frequency, the review-triggering events and the content review frequencyA written parameter table in the SSP or training plan with a value for each ODP and an approval date
Examine: policy and proceduresIncident response policy and procedures address training for system users by role, including the ODP valuesApproved incident response policy and procedures showing the training section and version history
Examine: training procedures and curriculumThe training procedure describes who is trained, on what, how often and how content is updated, and the curriculum matches the rolesTraining procedure, curriculum outline mapped to roles, and evidence of the last content review
Examine: training materials and incident response planMaterials reflect the current incident response plan, including reporting paths and responsibilitiesCurrent slide decks, labs or e-learning modules with version numbers, and the matching plan revision
Interview: personnel with training and operational responsibilitiesTraining owners can explain how role-based content is chosen, scheduled, delivered and refreshedNamed owner for the training program and a walk-through of one recent training cycle
Interview: personnel with security responsibilitiesResponders and system users can describe the incident response duties they were trained on and how they would actSample interviews with responders, administrators and general users matched to their training records
Common finding: undefined ODPsOrganization leaves one or more of the four parameters without a value, so the requirement cannot be assessed as metCompleted parameter table signed by the accountable owner before the assessment starts
Common finding: training does not match rolesEveryone receives the same generic course, or responders have no role-specific exercisesRole-to-curriculum matrix showing differences between user, responder and administrator content

Implementing 03.06.04 in the order an assessor expects

This sequence turns the 03.06.04 requirement into a defined ODP decision record, a role-based training program and tracked completion evidence that an assessor can examine and check against the incident response plan. Each step ends with an artifact you can hand over.

  1. Define the four organization-defined parameters

    Before anything else, the organization decides the four ODP values for 03.06.04: the time period within which training must be provided to users, the frequency of refresher training after initial training, the events that trigger a review of training content, and the frequency of content review and updates. NIST does not assign these values, and if the federal agency that holds the contract does not specify them, the nonfederal organization must assign them. The contracting officer or program office should be asked whether any values are already set. Accountable owners in security and compliance approve the decisions. The output is a signed ODP decision record that states each value, its rationale and its approver, because the assessor checks that every value is defined.

  2. Map incident response roles to training needs

    Identify every role in the incident response process, such as the incident response lead, responders, system administrators, help desk staff, communications and legal contacts, and general system users who must report suspected incidents. For each role, record the duties it carries under the incident response plan and the system access it holds. The Rev. 3 discussion of 03.06.04 points to 03.02.02 role-based training, so the matrix should show how incident response duties differ from general security awareness content. The output is a role matrix that links each role to its duties, its system access and the training it must complete. Confirm the matrix against the current incident response plan so the two documents do not diverge.

  3. Build role-specific curriculum and materials

    For each role in the matrix, write curriculum that covers the duties that role performs in the incident response plan, including how to recognize and report a suspected incident, how responders triage and contain events, and how communications are handled. Store the curriculum, the training materials and the assessment questions under version control, with the owner and review date recorded in each file. Assessors examine the curriculum and training materials directly, so they should match the procedures for incident response training and the plan itself. The output is a versioned curriculum set with one entry per role, each traceable to the role matrix.

  4. Schedule initial and recurring training

    Using the time period and frequency values from the ODP decision record, set the deadlines for initial training after a person assumes an incident response role or gains system access, and the intervals for recurring training. Include a trigger for training when system changes require it, such as a new logging platform, a new incident case tool or a change to reporting paths. Publish the schedule in a training calendar that names the course for each role and the owner who runs it. The output is a training calendar tied to the incident response plan, with each entry linked to an ODP value so an assessor can trace the schedule back to the decision record.

  5. Set triggers for content review and updates

    Configure the review events defined in the ODP record, such as a material change to the incident response plan, a change to the systems in scope, a lessons-learned report after a significant incident, or a change in reporting obligations. Set the recurring content review interval from the ODP record and assign an owner who records each review. Keep a change log that shows when content was reviewed, what changed and who approved the change. The output is a review log that shows the review events fired and the content was updated where needed, which is the evidence an assessor uses to test the review ODPs.

  6. Track completion and retain evidence

    Set up a completion record for each user and role. Learning platforms can mark activities complete under different conditions, such as when a learner views material, receives a grade or ticks an activity manually, so confirm which condition the program uses and record it in the curriculum documentation. Compare completion records against the training calendar each reporting period and follow up on overdue users. Retain the completion records, the curriculum versions and the review log together so they can be produced during an assessment. The output is a completion report that shows each user's role, training dates and status, which the assessor can check against the ODP values and the role matrix.

Evidence that shows incident response training was delivered and kept current

An assessor testing 03.06.04 will examine the policy, curriculum and plan, then interview the people who run incident response to confirm the training matches what the documents say. The cards below cover the records that connect those two checks, and the tools that can hold them.

ODP decision record

Because 03.06.04 leaves four values to the organization, the first artifact an assessor asks for is a signed record of the time period for initial training, the refresher frequency, the events that trigger a content review, and the review frequency. Each value should name the owner who approved it and the date. If a federal agency or contract specifies values, record that source. Check that the values in the training plan match the values in this record exactly.

Role-to-training matrix

A matrix that maps each incident response role, such as incident commander, analyst, forensic lead, and system administrator, to the training modules that role must complete shows that training is consistent with duties. Include the trigger that starts each requirement: assuming the role, gaining access to a system, or a system change. Confirm that the matrix is reviewed when roles change, and keep the reviewed version with a date.

Curriculum and materials with version history

The curriculum, slide decks, lab guides and tabletop scenarios are the content an assessor examines. Keep each version with its date, author and the reason for the change, so you can show that content was updated after defined events and at the defined frequency. Tie the version history to the incident response plan and to any lessons from exercises run under 03.06.03, so the training reflects the current plan.

Per-user completion records

Completion records should show each user, the role they held, the module, the completion date and the trigger that required the training. Moodle's activity completion can mark an activity complete when a learner views it, when they receive a grade, or when someone ticks it manually. Viewing alone does not prove understanding, so set the completion condition to a graded assessment for role-specific modules and confirm that the setting is applied to every course. Verify the export in your own environment before the assessment.

Post-change training records

When a system change requires new incident response knowledge, such as a new logging source, a new containment tool, or a changed escalation path, the training record should link the change request to the session that followed. An assessor will look for this link between change management and training. Record who was trained, when the session took place, and which change it addressed, and check that the record is kept with the change ticket.

Exercise outputs and case evidence

Tabletop and simulation outputs, including attendance, scenario scripts, and after-action notes, show that training was practical. DFIR-IRIS keeps each case as one record with assets, indicators, tasks, evidence and a full audit trail, and it can build a timeline and reports from case data. Case records can show that trained responders worked real incidents, but confirm in your own environment how the platform stores the link between a responder and the training they completed.

Setting the four organization-defined parameters for 03.06.04

The requirement cannot be completed until your organization sets four organization-defined parameters (ODPs). The first is the time period within which system users must receive incident response training after they take on an incident response role or gain system access. The second is the frequency of refresher training after that initial session. The third is the set of events that trigger a review of the training content, such as a significant incident, a change to the incident response plan, or a change to the systems users operate. The fourth is the frequency at which the content is reviewed and updated on a routine basis. NIST does not assign these values. If the federal agency that holds your contract does not specify them, the nonfederal organization must assign them itself, and the assessor will expect to see the values in place.

Start by asking the contracting agency, and the applicable DoW guidance, whether any of the four values are fixed. The DoW's pending FAR overhaul proposal would have contractors use ODP values published by the DoW CIO, and that rule was not final as of October 2026, so confirm the current position in writing before you rely on it. Where no values are supplied, pick values that match your real staffing turnover, your incident volume and how often your systems change. Ask whether the agency expects a specific maximum period for new responders, and whether it treats a change in the system boundary as a required trigger for training review. Record each answer in the system security plan or a training standard that names the owner of each parameter.

Document the rationale for every value, not only the value itself. A short record for each ODP should state the value, the source (agency direction or your own decision), the reasoning and the date of approval. Then show that the values are applied: the training records should show that new responders were trained within the set period, and the content review log should show reviews at the set frequency and after each defined event. An assessor testing this requirement will look for the values, for evidence they were followed, and for a reason someone can explain. A value that exists only in a policy document, with no training records behind it, will not show that the requirement is met.

What meeting 03.06.04 costs in money and effort

This table breaks down the cost components of meeting 03.06.04 training requirements, showing who does the work, whether each cost is one-time or recurring, and what drives it up or down. Read it as a checklist for building a quote, since no price is stated here and the main effort sits in role mapping and keeping content current.

Cost componentWho does the workOne-time or recurring, and main drivers
Role mapping and curriculum designSecurity staff and incident response leads, sometimes with an implementation partnerOne-time for the first build, then recurring when roles change. Drivers: number of distinct incident response roles, number of systems in scope
Learning platform licensingProcurement, with the vendorRecurring if a commercial platform is used. Open-source options such as Moodle remove license spend but move cost to hosting and administration
Self-hosting and administration of the training platformPlatform engineering staff or an implementation partnerOne-time setup, then recurring for patching, backups, access control and upgrades. Drivers: hosting model, user count, required availability
Content upkeep after system changesSecurity engineers and system owners who understand the changeRecurring. Drivers: frequency of system changes, number of events that trigger a content review, and the review frequency the organization defines for 03.06.04
Instructor or external content developmentInternal instructors, or an external trainer for specialized materialMostly one-time for the initial material, with recurring updates. Drivers: number of training tracks and whether material is built in-house or bought
Completion record managementTraining administrators and compliance leadsRecurring. Drivers: number of users, turnover, and how often records must be pulled for review. Confirm how the chosen platform records completion, since some track only view or grade events
Assessor sampling during the assessmentCompliance lead, with the independent assessor doing the samplingRecurring at each assessment cycle. Drivers: how many training records and curriculum versions the assessor samples. Ask the assessor how they will sample before work starts

Who does what for incident response training: your team, a partner and the auditor

Your organization owns the requirement. Only you can set the four organization-defined parameters for 03.06.04: the time within which training must be delivered to new responders or newly granted users, the frequency of refresher training, the events that trigger a content review, and the frequency of review and update. Your team also decides which roles carry incident response duties, because the training must match those roles. Under NIST's guidance, the federal agency holding the contract is responsible for how SP 800-171 is applied, so confirm any values the agency specifies before setting your own.

  • ODP decisions: Record the four parameter values in your system security plan or incident response training procedure, with the reason for each value.
  • Role mapping: Maintain a list of who holds incident response duties, including engineers, help desk staff, executives and system administrators, and which module each role must complete.
  • Content approval: Review and sign off the training curriculum and materials before they are used, and again after each triggered review.
  • Records: Keep completion records, dates, role assignments and content versions in a form an assessor can sample.
  • Change tracking: Log system changes that require training so you can show the trigger was acted on.

Before any outside work starts, check that the parameter values and role list are written down and approved by a named owner.

Where incident response training programs fall short of 03.06.04

Most incident response training programs fail 03.06.04 in predictable places: the organization-defined parameters were never set, the course is the same for everyone, and the records prove little. Each gap below is easy to miss in an assessment because the training still exists on paper, so check the parameters, roles, triggers and records together.

ODP values never defined

03.06.04 has four organization-defined parameters: the time within which training is provided, the frequency of refresher training, the events that trigger a content review, and the frequency of content review. Rev. 3 leaves these values to the organization, so an assessor will check that each one is written down and that the training matches it. Fix: record all four values in the incident response plan or training procedure and tie each to an owner and a date.

One generic course for every role

03.06.04 requires training consistent with each user's role, so the executive who approves external notifications and the help desk agent who receives a suspicious email need different content. A single course for all staff usually covers the basics but leaves responders and decision makers untrained on their actual duties. Fix: map each incident response duty to a role, then build short modules for each group and document which roles take which module.

No training after system changes

The requirement ties training to system changes, so a new logging platform, a cloud migration or a new response tool can make existing training out of date on the day it goes live. Programs that only run an annual session miss this trigger entirely. Fix: add a change-management checkpoint that asks whether a change affects incident response duties and, if so, schedules targeted training before the change is approved.

Content not reviewed after incidents

The content review ODPs define which events start a review, and real incidents are the events that most often reveal gaps in training material. When lessons from an incident never reach the course, the next responders repeat the same mistakes. Fix: add a post-incident review step that checks whether the training content, the event list and the materials need changes, and log the decision even when no change is made.

Completion records show clicks, not understanding

Learning management systems often mark an activity complete when a learner opens it, receives a grade or ticks a box, so a completion report can look healthy while nobody has demonstrated the duty. Assessors interviewing responders will expose this quickly. Fix: require a short knowledge check or a practical exercise for responder roles, and confirm with your platform vendor which completion condition each activity uses before you rely on the report as evidence.

Training disconnected from the response plan

The Rev. 3 discussion of 03.06.04 points to role-based training (03.02.02), and the incident response plan under 03.06.05 assigns the responsibilities that training must teach. When the course uses a different escalation path, contact list or severity scale from the plan, staff learn the wrong procedure. Fix: build the course content from the current plan, reference plan version numbers in each module, and update training when the plan changes.

Questions buyers ask about 03.06.04 cost, effort and outside help

How much effort does 03.06.04 incident response training take?

The effort depends less on the requirement itself than on how many people hold incident response roles and how often those roles change. The requirement asks for training that matches each role, delivered within a defined time of assuming the role or gaining system access, after system changes that call for it, and at a defined frequency afterwards. Four organization-defined parameters must be set: the initial training window, the refresher frequency, the events that trigger a content review, and the review cycle. Effort rises with the number of distinct roles (responders, system administrators, managers, help desk staff), the number of systems, and how often staff turn over. The largest one-time cost is usually building curriculum and materials that match your incident response plan. Ask any partner to break its quote into curriculum design, delivery setup, and recurring updates.

Can we meet 03.06.04 with in-house staff alone?

Yes, in principle. The organization owns its controls, so internal staff can write the training, deliver it and keep the records. Outside help is most useful when the team lacks experience mapping roles to incident response duties, or when it needs a second reviewer for the parameter values. The assessor will examine the incident response policy and procedures, the training curriculum and materials, and the incident response plan, then interview people with training and operational responsibilities. Whoever does the work, the organization must be able to explain why each parameter value was chosen and show that staff actually completed the training. Whether to outsource is a question of capacity and skill, not of whether the requirement can be met.

What does our team need to provide for the work?

Plan for named contributors from incident response, IT operations, security engineering and HR or learning administration. Incident response leads must confirm the roles and duties that each group performs during an incident. Platform owners must confirm where training records will be stored and who can export them. Management must approve the four parameter values, because they become commitments an assessor will test. Expect the team to supply the current incident response plan, role descriptions, system inventory and any past training history. Without these inputs, any partner will spend much of the engagement reconstructing them, which typically adds time and cost to a fixed-scope quote.

How long does it take to prepare 03.06.04 evidence?

Preparation time depends on the state of your existing documentation. An organization with a current incident response plan, defined roles and a learning system with completion history will need less time than one starting from scratch. The work falls into three steps: setting the parameter values and recording the rationale, building or aligning curriculum to each role, and running enough training that completion records exist for the people the assessor will sample. Evidence must cover a period of operation, so the calendar time to collect it can exceed the time to write the materials. Ask any partner for a written timeline that separates document work from the period needed to generate records.

Will an assessor accept records from a learning platform?

An assessor will look at what the records show, not at the brand of the platform. Learning management systems can produce evidence of who was enrolled, when they completed training, and which curriculum they took. Moodle, for example, has activity completion that marks an activity complete when a learner views it, receives a grade, or ticks it manually, depending on the conditions set for the activity. That behavior matters: if completion means only that someone opened a page, the record may not show that the person was trained. Set completion conditions that reflect real understanding, such as a graded quiz or a tabletop exercise sign-off, and export the records with dates. Confirm acceptance with your assessor before relying on any specific design.

What should we ask a partner for in a fixed-scope quote?

A fixed-scope quote should state the scope in writing before work starts. Ask the partner to list the roles in scope, the curriculum and materials to be produced, the delivery method, the parameter values it will propose, and the evidence package it will hand over. Ask which items are one-time (curriculum build, parameter decisions, initial delivery) and which recur (annual or event-driven content reviews, new hire training, refresher delivery). Confirm what the partner will not do: it does not issue audit reports or certifications, and an independent assessor must still assess your organization. Ask for the assumptions behind the quote, such as the number of roles and systems, so changes can be priced against them. DeployOpen issues quotes from written scope and does not publish a price list.

Who is responsible for 03.06.04 if an assessor finds a gap?

The organization remains responsible for its controls, and a gap is the organization's to fix. NIST states that application and implementation of SP 800-171, and any compliance issues, are the responsibility of the federal agency holding the contract, regardless of organization size. A partner can prepare systems, curriculum and evidence, but it cannot certify the result. Contracts should state who corrects findings, how quickly, and whether rework is included in the fixed scope or billed separately. Clarify this before signing, because the answer determines how much risk sits with each party.

How DeployOpen scopes and prepares 03.06.04 evidence

DeployOpen works on 03.06.04 Incident response training as a written, fixed-scope piece of work inside your own infrastructure. We help you set up the training records, role mapping, curriculum and review cycle that an assessor will examine, while your organization owns the control and an independent assessor decides whether it is met.

How we scope

  • The written scope names every system user group that holds an incident response role or access to in-scope systems.
  • The scope records which ODP values your organization must set for the training time period, refresher frequency, review triggers and review cycle.
  • The scope lists the existing policies, incident response plan, curriculum and training logs that will be examined as evidence.
  • Scope and deliverables are agreed in writing before work starts, and a quote follows from that written scope.

How we build

  • We map each role to incident response duties and to the training modules that cover them, so records can be matched to people.
  • We configure your self-hosted learning platform to track completion per learner and to flag users who are overdue for training.
  • We set up review triggers for system changes and incident lessons, so curriculum updates are logged with dates and approvers.
  • We test the training workflow with your team to confirm the records show who was trained, on what, and when.

How we hand over

  • You receive documented ODP decisions, role-to-training matrices, curriculum version history and the procedure for running training.
  • Evidence packs are indexed to the 03.06.04 determination statements so an assessor can trace each claim to a record.
  • Runbooks explain how to export completion reports, retain them and answer assessor questions about training content.
  • Handover notes list open items your organization must confirm with its assessor or contracting authority.

How we support

  • Ongoing support, upgrades and curriculum reviews are available as a retainer after handover.
  • A retainer can cover refresher cycles, new system onboarding and changes to the incident response plan that alter training content.
  • Support scope and frequency are defined in writing so your team knows what is covered and what remains internal.
  • Your assessor, not DeployOpen, decides whether the evidence satisfies 03.06.04.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.