03.06.01 Incident handling: requirements and evidence

What 03.06.01 incident handling asks for and why assessors focus on it

Requirement 03.06.01 asks the organization to implement an incident-handling capability that is consistent with its incident response plan and covers preparation, detection and analysis, containment, eradication and recovery. In plain terms, when something goes wrong with a system that holds CUI, people already know who acts, what they do first, how they stop the damage, how they remove the cause and how they bring systems back. The risk it addresses is simple: a suspected compromise that is handled ad hoc can let an attacker keep reading CUI, spread into connected systems or destroy the evidence needed to understand what was taken. The requirement is about a working capability, not a document. A plan on a shelf does not satisfy it, and assessors look for proof that the handling steps were followed in practice, usually through case records, tickets and post-incident reviews.

Four things usually make this hard. Many organizations have no defined handling workflow beyond "call the help desk," so triage and escalation depend on whoever answers the phone. Evidence trails are thin because analysts work in chat, email and personal notes, and nothing records the timeline, the actions taken or the approvals. Ownership is unclear between IT operations, which controls the systems, and the security function, which is expected to lead the response. And the handling process is not connected to the plan that governs it, so the two drift apart over time. Before scoping work, confirm which version of the requirement your contract uses. Under Rev. 3 the number is 03.06.01. Under Rev. 2 the same requirement is numbered 3.6.1, which is the numbering that CMMC Level 2 assessments use, and the change analysis classes the Rev. 3 wording as a significant change with more detailed and foundational tasks.

Before you engage an implementation partner, decide who has authority to declare an incident, who leads containment on each system type, and where case records will live. Ask for the handling workflow in writing and a sample case showing each phase from preparation through recovery. The implementation work is to prepare systems, tooling and evidence so that these records are produced as a matter of course. Only the organization owns its controls, and the assessor decides whether the capability meets the requirement.

Which systems, teams and third parties fall under incident handling

The scope of 03.06.01 follows the CUI system boundary defined in the system security plan. Each card below is a scoping decision that changes how much work the incident-handling capability carries and how many log sources an assessor will ask you to explain.

CUI systems and their security tooling

Every system that stores, processes or transmits CUI sits inside the boundary, and so does the tooling that watches it, such as endpoint agents, log collectors, SIEM and firewalls. Ask whether each of these components is inside the boundary or is an external service that receives its logs. Every system in scope produces logs and alerts that an assessor may ask you to walk through, so the count of in-scope systems is the first number to settle.

IT operations handling roles

IT operations staff usually detect the first symptoms, isolate hosts and restore services, so their actions during containment and recovery are incident-handling actions. Document who can disconnect a system, revoke credentials and rebuild a host, and confirm that those people are trained for the role. Assessors often interview these staff to test whether the documented procedures match what they actually do.

Security team and CUI owner decisions

The security team leads analysis and decides when an event becomes an incident, while the CUI owner decides what information was exposed and how serious the impact is. Confirm in writing who holds each decision and who can approve containment that stops a business process. Unclear ownership here is a common reason handling steps fail when a real event occurs.

Legal and management escalation

Legal counsel and senior management are part of the handling chain when an event may trigger contractual, regulatory or disclosure duties. Map which events they must see and how quickly, and record who can authorize external communications. Keep these steps linked to the reporting requirements in 03.06.02 so that escalation and reporting do not run on separate, conflicting timelines.

Managed SOC and monitoring providers

A managed SOC that monitors CUI systems or receives their alerts becomes part of the incident-handling capability. Its contract, access to log data and escalation path need to match the procedures in the incident response plan. Confirm what the provider can do alone, what requires your approval, and where its records are kept, because the assessor will ask for them as evidence.

Cloud providers and forensic firms

Cloud platforms that host CUI hold logs and snapshots that handling depends on, and external forensic firms may take custody of evidence during analysis. Check what the cloud provider retains, how you obtain those logs during an event, and what the forensic contract says about evidence handling and access. Each of these relationships should be documented in the system security plan and the incident response plan.

How an assessor tests incident handling under SP 800-171A

This table maps the six determination statements for 03.06.01 to the examine, interview and test methods an assessor uses, the evidence they ask for and where organizations most often fall short. Read each row as one question the assessor asks, then check your own records against the evidence column before the assessment starts.

Method and object	What the assessor examines, interviews or runs	Evidence requested	Common findings
Examine: policy and procedures	Incident response policy and the contingency planning policy, checked for scope, approval and review dates	Signed policy, version history, approval record and last review date	Policy exists but is unapproved, out of date or does not name the systems in scope
Examine: incident handling procedures	Written steps for preparation, detection and analysis, containment, eradication and recovery	Runbooks or playbooks with owners, decision points and escalation paths	Procedures cover detection only, or steps are generic and not tied to CUI systems
Examine: incident response planning procedures	How the plan is written, reviewed and updated, and who approves changes	Planning procedure, plan revision log, review records after exercises or real incidents	No documented method for updating the plan after lessons learned
Examine: incident response plan	Plan content for the incident handling capability, roles, contacts and recovery steps	Current plan with named roles, contact lists and the systems it covers	Plan lists people who have left, or omits recovery and eradication steps
Interview: incident handling and planning staff	Responders and planners explain their role, the steps they follow and how they escalate	Interview notes, role assignments and training or acknowledgment records	Staff describe a different process than the written procedure
Interview and test: contingency planning staff and the handling capability	Contingency staff explain how incident handling links to recovery, and the handling capability is run or demonstrated	Recent exercise or incident records, tool access logs and a walk-through of one scenario	Capability exists on paper but cannot be shown working end to end, or tool access is not restricted to responders

The order to build an incident-handling capability that passes review

This sequence turns 03.06.01 from a requirement on paper into a working capability, with each step producing an artifact an assessor can examine. Work in this order so that procedures, tooling and records line up with the incident response plan from the start.

Confirm the incident response plan and its roles
Start by checking that the incident response plan names who declares an incident, who leads handling, who approves containment actions and who speaks to customers, regulators or contracting officers. The plan itself is covered under 03.06.05, but 03.06.01 requires the handling capability to be consistent with it, so every later step must reference the same roles. Done when each named role has a current contact path and the plan has an approval date. Assessors will compare the plan against the procedures and interview the people it names.
Define handling procedures for each phase
Write one procedure per phase: preparation, detection and analysis, containment, eradication and recovery. Each procedure should state the trigger, the inputs, the decisions, the people involved and the record that must be kept. Keep the procedures in the same document set as the plan so the link is visible. Done when a reviewer can follow an example incident from alert to closure using only the written procedures. SP 800-171A Rev. 3 examines procedures for incident handling and procedures for incident response planning, so both need to exist as separate, dated documents.
Deploy detection and log sources
Connect the systems in the CUI boundary to a detection layer, such as a SIEM or host-based monitoring, so that security-relevant events reach analysts. Open-source options include Wazuh, which compares decoded events against a ruleset of over 3,000 built-in rules and decoders plus custom rules, and OpenSearch Security Analytics, which matches ingested logs against Sigma rules. Confirm which log sources feed each tool and which alerts reach a human. Done when a test event from a sample host produces a recorded alert and a documented triage decision. Assessors will ask for the source inventory and the rule set in use.
Set up case tracking and evidence handling
Choose a case management tool and define how cases are opened, linked to alerts, assigned and closed. DFIR-IRIS, under LGPL-3.0-or-later, keeps each case as one record of assets, indicators, tasks and evidence with an audit trail, and it logs evidence with SHA-256 verification and chain of custody. Define who may close a case and what must be attached before closure. Done when a sample case shows the full audit trail, hashed evidence and a generated report. This step produces the records that 03.06.02 tracking and reporting depends on.
Define containment and eradication playbooks
Write playbooks for the incident types most likely to affect the environment, such as credential compromise, malware on an endpoint and unauthorized data movement. Each playbook should list containment options such as isolating a host, disabling an account or blocking an address, the approval needed for each, the business impact of each option and the eradication steps. Where automation is used, Shuffle workflows can be started by a webhook, a schedule or a manual run, with app nodes that perform actions such as posting to chat or scanning a file. Done when each playbook has been reviewed by the people who approve containment and each automated step has a documented manual alternative.
Establish recovery and lessons-learned steps
Define how systems return to service after eradication, including who verifies clean state, how restored systems are monitored for recurrence and when CUI handling is confirmed to be safe again. Add a lessons-learned review that feeds changes back into the procedures, detection rules and playbooks, with a record of each change. Done when a closed case shows a recovery verification entry and a lessons-learned record that led to at least one documented update. Assessors look for this loop because it shows the capability improves rather than only executing.
Run a dry-run and capture the records
Run a tabletop or simulated incident through the full chain, from a seeded alert in the detection tool through case creation, containment, eradication, recovery and the lessons-learned review. Capture the alerts, case record, evidence hashes, decisions, approvals and the review notes. Record any gaps and close them before the capability is treated as operating. Done when the dry-run record is dated, signed off by the incident lead and filed with the procedures. Testing itself is covered under 03.06.03, so the dry-run should be documented so that it can serve that requirement too.

Open-source tools that produce incident-handling evidence

Detection tools produce the first records of an incident-handling capability: the events, alerts and findings that show the organization noticed something and began analysis. Wazuh and OpenSearch Security Analytics both fall here, but they work differently. Wazuh focuses on host and endpoint telemetry, while OpenSearch Security Analytics focuses on rule-based matching across ingested logs. Each produces records an assessor can examine, provided the logging and retention settings are configured and documented.

Wazuh (GPL-2.0-only): Decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules.
Wazuh alert files: Writes matching alerts to alerts.log and alerts.json, and forwards them to the Wazuh indexer for review in the dashboard.
Wazuh ATT&CK mapping: Maps alerts to MITRE ATT&CK, which helps analysts classify activity during analysis.
OpenSearch Security Analytics (Apache-2.0): Runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules, and records matches as findings with rule, log type and severity.
Correlation and alerting: Its correlation engine links findings across log types in a correlation graph, and it sends alerts to channels such as Slack or email.

Confirm with your security team that the detection tool covers your in-scope log sources and that alert records are retained for the period your plan defines.

Which evidence passes 03.06.01 and how to keep it current

An assessor testing 03.06.01 looks for records that show the incident-handling capability operates, not a written description of it. The cards below cover the artifacts most often requested, and each one needs a routine that keeps it dated and complete between assessments.

Incident response policy and handling procedures

The approved policy and the step-by-step handling procedures for preparation, detection and analysis, containment, eradication and recovery. Assessors examine these first, then compare them with what happened in the records they sample. Keep version history, approval dates and owners on each document. Review the procedures after every significant system change, after every real incident, and at a set interval your organization defines, and record each review even when nothing changed.

Dated incident and exercise case records

Case records for real incidents and for exercises, each with open and close dates, assigned responders, actions taken and the outcome. Assessors choose several records at random and check that each step followed the procedures. Export case data at a fixed cadence, such as monthly, into a read-only store so records cannot change after the fact. Tools such as DFIR-IRIS keep each case as one record of assets, IOCs, tasks and evidence with a full audit trail, which helps show who changed what and when.

Detection and alert records

Evidence that the organization detects events that matter. Export alert records showing rule identifiers, timestamps, severity and the triage decision made on each alert. Check that detection rules are reviewed and updated when systems change, and keep the rule set under change control. A SIEM or detection platform such as Wazuh writes alerts to files and an indexer that can be exported for sampling. Confirm which log sources feed detection in your environment and document any gaps.

Evidence-handling logs with hashes and chain of custody

Records showing how evidence was collected, stored and transferred during an incident. Each item needs a hash, such as SHA-256, recorded at collection and checked at each handover, plus a chain-of-custody entry naming every person who held it. Assessors check whether the hash values still match the stored files. Verify hashes on a schedule, not only when an incident occurs, and confirm that custody logs cover analysts, storage and any outside party who received the evidence.

Lessons-learned records

Post-incident reviews that record root cause, what worked, what failed and the changes made to procedures, detection or training as a result. Assessors look for a link between each finding and a tracked action with an owner and a due date. Hold the review within a period your procedures define after each incident or exercise, and track open actions until they close. A review that produces no action items is often questioned because it suggests the review did not examine the response.

Proof that handling matched the response plan

Records that tie each sampled incident back to the incident response plan, showing the responsibilities, escalation paths and reporting steps the plan defines were followed. Map plan sections to case records in a simple matrix, and note deviations with the reason. Assessors compare the plan's assigned roles against the people named in the case timeline. Update the matrix whenever the plan or staffing changes, so the evidence reflects the plan in force on the date of each incident.

What meeting 03.06.01 costs in money and effort

This table compares the main cost components of running an incident-handling capability for 03.06.01, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No dollar figures are published here, so use the drivers and quote checklist to request a fixed-scope estimate and confirm assessment expectations with your contracting officer or assessor before you commit budget.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses	Recurring if subscription; none for self-hosted open-source	Choice of SIEM, case management and automation platforms, and number of log sources	Self-hosted Wazuh, OpenSearch, DFIR-IRIS and Shuffle remove license spend, but hosting, patching and storage remain operating effort
Engineering time for detection content and playbooks	One-time build, then recurring tuning	Number of log sources, rule coverage needed, and how many incident types have written playbooks	Start with a defined set of incident types and tune rules from real alerts rather than building every rule at once
Staff time for handling and exercises	Recurring	Team size, on-call coverage, and the exercise frequency your organization sets for 03.06.03	Assign named roles in the plan, reuse tabletop scenarios, and record exercise results in the same tracker used for cases
Evidence upkeep	Recurring	Volume of case records, retention periods, and how often the plan and procedures change	Generate evidence from case data where your tools allow, and keep an evidence index that maps each determination statement to a file
External testing or review of the capability	Recurring or per engagement	Scope of testing, whether the review covers the detection stack, and whether results feed a POA&M	Scope reviews to the incident-handling capability and reuse prior findings to narrow each new engagement
Assessor sampling and preparation	Recurring per assessment cycle	Number of incidents or exercises an assessor selects to examine, and how many interviews are held	Keep case records complete and consistent so sampled items can be produced quickly without rework

Who does what: your team, an implementation partner and the auditor

Your organization owns the incident-handling capability and is accountable for it under the contract or agreement that requires NIST SP 800-171. NIST states that application, implementation and compliance are the responsibility of the federal agency that holds the contract, so the internal owner should be able to explain how the capability works without relying on a vendor. Staffing, on-call coverage and the decisions made during a live incident also stay in-house.

Ownership of the plan: Name an accountable owner for the incident response plan and the handling procedures, and confirm who approves changes to them.
Staffing and escalation: Assign people with incident handling responsibilities, define backups, and decide who can declare an incident and who can order containment on production systems.
Reporting decisions: Decide what counts as a reportable event, who makes the call to notify, and when. DFARS reporting timelines and government-facing decisions stay with the organization and its contracting officer, not with a partner or tool.
Business trade-offs: Accept the operational impact of containment actions such as isolating hosts or revoking accounts, and document who approved them.
Evidence of operation: Keep the records an assessor will sample, including case records, approvals and lessons learned.

Check that the named owner can produce a current plan and at least one recent case record without help from an outside party.

Where organizations fall short on incident handling and how to close each gap

Most incident-handling gaps show up at assessment time, not during a real incident. An assessor asks to see how a procedure was run, which alert was triaged and what evidence was preserved, and the answer is often a document rather than a record. The cards below cover the gaps we see most often and the closure step for each.

Procedures stop at the plan

The incident response plan names phases such as containment and eradication, but no one has written the operational steps analysts follow at 2 a.m. An assessor testing 03.06.01 will ask for the procedures for incident handling and check that they match the plan. Close the gap by writing a runbook for each phase, with the decision owner, the tool used and the record produced. Walk one runbook through a tabletop exercise to confirm it works.

Alerts nobody triages

Detection tools generate alerts, but no one is assigned to review them, so the detection phase exists on paper only. Check whether each alert source has an owner, a severity threshold and a documented disposition such as closed as benign or escalated to a case. Wazuh alerts written to alerts.json or OpenSearch findings can feed a triage queue, and the queue's history becomes evidence that detection and analysis actually run.

No case record for minor incidents

Teams often handle small incidents in chat or email and never open a formal record, so when an assessor asks for a sample of handled incidents there is nothing to show. Open a case for every event that passes triage, even if the outcome is benign, and record the decision. A case management tool such as DFIR-IRIS keeps assets, indicators, tasks and evidence in one record with an audit trail, which gives the assessor a sample that reflects normal operations.

Evidence without hashes or custody

Forensic artifacts copied during an incident are often stored without a hash, a collector name or a transfer log, which makes later integrity claims hard to defend. Require a SHA-256 hash at collection, a chain of custody entry for every transfer and a storage location with restricted access. Confirm with counsel which evidence must be preserved for reporting obligations, since the DFARS clause also covers malware and media preservation.

Containment without documented authority

Analysts isolate hosts, disable accounts or block traffic during containment, yet the approval path is unwritten, so no one can show who authorized the action. Define which actions an analyst may take alone, which need the incident commander and which need business owner approval. Log each containment decision with its time, approver and reason, and check that the logged approvals match the authority matrix.

Lessons learned that change nothing

Post-incident reviews identify weaknesses, but the findings never reach the runbooks, detection rules or training, so the same gap recurs. Assign each finding an owner and a due date, and track it to closure in the case or the plan of action. An assessor testing recovery and improvement will look for a link between the review and the updated procedure, not just a meeting note.

How much work incident handling takes and what buyers ask before hiring help

What does 03.06.01 incident handling cost, and what drives the cost?

No researched figure is available for this requirement, so the cost depends on your environment and scope. Most of the spend falls into three groups: staff time from your own security, IT and operations teams, the tooling you run (SIEM, EDR, case management, automation), and any outside help for preparing systems, writing procedures or running tests. The main cost drivers are the number of systems inside the CUI boundary, how much logging already exists, whether you already have detection tooling, and how many roles must be trained and exercised. Costs are mostly one-time for building the capability and recurring for staffing, licenses, exercises and updates. Ask any provider for a written scope that separates one-time work from recurring work and names who performs each task.

How long does it take to build an incident-handling capability?

No researched duration is available, so the timeline depends on scope, the maturity of your current logging and response processes, and how many systems and teams are involved. Work usually moves in a sequence: confirm the incident response plan and roles, make sure logs reach a central place, set up case tracking and triage, then test the process. Each step can take longer if approvals, access to log sources or staff availability are limited. Request a timeline in the written scope with dependencies listed, rather than relying on a generic estimate.

Can our own team implement 03.06.01 without outside help?

Yes, many organizations do this in-house, provided they have people who can write and maintain procedures, operate detection and case tools, and run exercises. The hard parts are usually not the tools but the consistency of the work: alerts must be triaged the same way, evidence must be preserved, and the response must follow the incident response plan. Outside help is most often used to prepare systems and evidence, configure open-source platforms inside your environment, or test the capability. Your team still owns the controls and the decisions made during an incident.

What does the work require from our staff?

The work needs named people in clear roles, access to logs, and time for exercises. Expect to assign people who own incident handling decisions, people who own the incident response plan, and people who manage contingency planning, because the assessment interviews these roles. You will need read access to log sources and the ability to create and close cases, plus a path to the systems that contain CUI. Exercise time is recurring, so plan for staff to join walk-throughs or tabletop sessions at the frequency your plan defines. Confirm these commitments in writing before work begins.

Does DeployOpen issue a NIST SP 800-171 certification or attestation for 03.06.01?

No. DeployOpen plans, implements, configures and documents the systems, controls and evidence that support 03.06.01, and runs security testing where it is in scope. It does not issue assessment reports, attestations or certifications. For DoD contracts, the assessment is performed by the government or the process defined by the applicable program, and the organization owns its own compliance statements and the submitted score. Confirm with your contracting officer or assessor which evidence they will accept.

How do Rev. 2 and Rev. 3 numbering affect the work for 03.06.01?

Rev. 3 uses the number 03.06.01, while Rev. 2 uses 3.6.1, and CMMC Level 2 still assesses against the Rev. 2 numbering. NIST's change analysis traces 03.06.01 to Rev. 2 requirement 3.6.1 and classifies the change as significant, with more detail and foundational tasks in Rev. 3. In practice, the technical work is largely the same, but your evidence mapping, system security plan and procedures should cite the version your contract requires. Check which revision your contract or program names, because the DoD and FAR rules are changing.

Can 03.06.01 be placed on a POA&M under CMMC?

No, not for Conditional status. Under 32 CFR 170.21, the CMMC Level 2 requirement IR.L2-3.6.1 cannot be included on a plan of action and milestones to achieve Conditional status. Under 32 CFR 170.24, this practice is worth 5 points in the scoring methodology, so it must be fully met before you can be assessed at the level that depends on it. Read the current text of both sections with your counsel, because the CMMC program rules are subject to change.

How DeployOpen scopes and prepares incident-handling evidence

DeployOpen plans, implements and documents the systems and evidence behind 03.06.01 Incident handling inside your own infrastructure, under a written scope agreed before work starts. We prepare the incident-handling capability and its records for your assessor, but your organization owns the controls and only an independent assessor can issue a finding.

How we scope

Confirm which systems, teams and locations handle CUI and fall inside the incident-handling capability.
Agree in writing which SP 800-171A determination statements for 03.06.01 the engagement will prepare evidence for.
Record which incident response plan, procedures and roles already exist, and which must be written or revised.
Set out deliverables, timelines and exclusions in the written scope before any configuration begins.

How we build

Deploy the chosen open-source case management, detection and automation tools in your cloud account, data center or air-gapped network.
Configure alert intake, case tracking, evidence logging with hash verification and chain of custody for the incident-handling workflow.
Document preparation, detection and analysis, containment, eradication and recovery steps so each stage maps to a procedure an assessor can examine.
Test the workflow against sample alerts so the records you show an assessor reflect how the capability actually runs.

How we hand over

Deliver the configured platforms, runbooks and evidence artifacts listed in the written scope.
Walk your incident handlers and interviewees through the workflow so they can explain it accurately during an assessment.
Provide an evidence index that links each determination statement for 03.06.01 to the records that support it.
Transfer administration access and documentation so your team can operate the capability without us.

How we support

Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
Retainer work can cover platform upgrades, updated runbooks and tuning of detection content after changes to your environment.
Ask any provider to confirm in writing who signs the assessment outcome: only an independent assessor or certification body does.