IR.L2-3.6.1 Incident handling: requirements and evidence

What IR.L2-3.6.1 incident handling requires and why assessors reject plans alone

IR.L2-3.6.1 asks a defense contractor to establish an operational incident-handling capability for its organizational systems, and to show that this capability includes preparation, detection, analysis, containment, recovery and user response activities. The assessor is not checking whether a policy exists. They are checking whether the organization can actually run the cycle from a suspected event to recovery. This is a 5-point requirement under the CMMC Scoring Methodology. If it is scored NOT MET, it is subtracted from the maximum score of 110, and because it is worth more than 1 point, it cannot be placed on a POA&M under 32 CFR 170.21. Plan for it to be MET before the assessment, or the contractor cannot reach Conditional or Final Level 2 status.

A written incident response plan is necessary but rarely sufficient. Under NIST SP 800-171A, the assessment objectives for 3.6.1 are tested against potential assessment objects such as the incident response plan, incident handling and response assistance procedures, training curriculum and records, and tests of the incident-handling capability itself. A plan that has never been exercised usually shows gaps in named roles, contact lists, evidence storage locations and escalation decisions. Before an assessment, ask who is the incident commander, who can declare an incident, who calls the Affirming Official, and where the evidence from the last drill is kept. If the answers live only in the document, the requirement is at risk.

The hardest part is showing that the capability works in every phase, not only in detection. Many teams can produce an alert and a ticket but cannot show a documented containment decision, a recovery check or a record of what users were told. Walk each phase with a recent event or a tabletop record and confirm there is a dated artifact for it. Where you have no such record, that gap is the work to finish first. Confirm with your assessor, in writing, which artifacts they will accept as evidence of each phase before you build them.

Which systems, teams and third parties fall under incident handling scope

Incident handling under IR.L2-3.6.1 covers every system that stores, processes or transmits CUI, plus the security tools and people that detect and respond to events on them. The cards below separate the technical boundary, the internal roles, the external contacts and the third parties whose incidents must reach your team, since each choice changes how much work the capability requires.

CUI systems and their boundary

The incident-handling capability must reach every organizational system that stores, processes or transmits CUI, and the assessed boundary should match your system security plan. Confirm whether enclaves, shared services, backup systems and remote endpoints sit inside that boundary. A narrow boundary reduces monitoring work, but any CUI system left outside the plan becomes an unhandled gap that an assessor can find.

Security tools and log sources

Detection depends on which log sources feed the response process. Decide whether firewalls, identity providers, cloud control planes, endpoints and servers forward events to a central point, and who owns each feed. Every source you leave out is a blind spot in the detection phase, and the assessor will ask how an incident on that source would surface.

Endpoints and user devices

Endpoints are often the first place an incident appears, so decide whether laptops, workstations and mobile devices that touch CUI are covered by detection and by user-reporting procedures. Remote and off-site devices need a way to report suspicious activity when they are not on the corporate network. Check whether personal devices are used for CUI work, since those devices change both detection and containment steps.

Internal roles and decision makers

The capability depends on named people who detect, analyze, contain and recover, and on those who decide when to escalate. Assign an incident lead, technical responders, a communications contact and an executive approver, then confirm each person has a backup. Record the roles in the incident response plan so an assessor can trace who acts during a test or a real event.

External contacts and authorities

Incident handling needs a list of external contacts before an incident starts, including legal counsel, forensic support, your cyber insurer, law enforcement contacts and the government points of contact that your contracts require. Keep these contacts current and confirm how each is reached outside business hours. The list should feed the reporting procedures under IR.L2-3.6.2 Incident reporting.

Managed service and cloud providers

Third parties such as managed service providers, cloud hosts and SaaS vendors can detect or cause incidents on your CUI systems. Write contract terms that require them to notify you of incidents within a time you agree, to share relevant logs, and to name a contact for response. Assessors will expect you to know how a provider incident reaches your team, so confirm this before you rely on the provider.

How an assessor tests IR.L2-3.6.1 against NIST SP 800-171A objectives

This table maps the seven NIST SP 800-171A assessment objectives for IR.L2-3.6.1 to the test an assessor runs, the evidence they request and the findings that usually hold up a MET result. Read each row as a question the assessor will ask, then check whether your records answer it in final form. The main takeaway is that the requirement is MET only when every applicable objective is satisfied, so a gap in any one row can block the whole requirement.

Assessment objective	What the assessor tests	Evidence requested	Common findings
Operational capability established	Whether an incident-handling capability is actually in operation, not only described	Approved incident response plan, named team roles, contact list and evidence of how the plan is activated	Plan exists but has never been approved, dated or assigned to named owners
Preparation activities	Whether preparation covers tools, contacts, reporting channels and evidence storage before an incident occurs	Incident contact list, reporting mailbox or phone line, tracking system configuration, evidence storage decision	Contacts are outdated or reporting channel is unmonitored
Detection activities	Whether the organization can notice incidents through monitoring and user reports	Log sources feeding the monitoring tool, alert rule set, sample alerts and triage records	Detection depends on one log source or alerts go to no one with authority to act
Analysis activities	Whether alerts are triaged, scoped and documented in a consistent way	Case records with timelines, severity decisions and analyst notes from past or exercised events	Triage decisions are made in chat or email and never recorded in a case
Containment and recovery activities	Whether procedures show how affected systems are isolated and returned to service	Containment procedures, recovery runbooks, change records for restored systems and post-incident review	Procedures are generic and do not name the systems, accounts or backups involved
User response activities	Whether users know what to report and what to do, and whether the organization responds to their reports	Reporting instructions given to users, training records, examples of user-reported events and their handling	Users cannot name the reporting channel or reports are not logged
Plan and procedure testing and training records	Whether the plan, contingency plan, handling procedures and training curriculum exist, are current and were used	Final-form plan and contingency plan, response assistance procedures, training materials and attendance records, exercise reports	Drafts presented as final, training records missing for named roles, or no evidence the plan was ever exercised

How to build an operational incident-handling capability step by step

This sequence turns IR.L2-3.6.1 from a policy statement into a working capability that an assessor can observe. Each step produces a named artifact, so by the end the organization holds a plan, a contact roster, a reporting path, a tracking record and trained responders.

Confirm the scope of covered systems
Start by listing the organizational systems that store, process or transmit CUI, along with the people and service providers who operate them. Map the boundary against the system security plan so the incident capability covers the same assets the assessor will review. Done when the scope statement names every in-scope system and is approved by the system owner. Ask your assessor or consultant to confirm that the boundary matches your environment before you build on it.
Name internal and external contacts
Build a contact roster that lists who declares an incident, who leads analysis, who decides on containment, and who speaks for legal, HR and executive leadership. Include external contacts such as your managed detection provider, forensic firm, outside counsel and cloud or hosting support, with a primary and backup for each. Output: a roster with names, roles, phone numbers and escalation order, reviewed at least once a year and whenever staff change.
Set a reporting channel
Create one channel that any user can use to report a suspected incident, such as a monitored email address or a phone line with an after-hours route. Route it to the ticketing or case system rather than an individual inbox, and test that messages arrive. Output: a documented channel with its owner, hours of coverage and an acknowledgement procedure that users can follow without training on the plan itself.
Establish incident tracking
Select a system of record where every event is opened, assigned, worked and closed. It should hold assets involved, indicators, tasks, notes and evidence, and keep an audit trail of changes. Open-source options such as DFIR-IRIS can serve this role, but confirm features and hosting requirements against your own environment. Output: a working case template and a sample case that shows how a report moves from intake to closure.
Decide where and how evidence is stored
Define a restricted evidence repository with access logging, naming conventions and retention rules. Specify how evidence is collected, hashed and recorded in chain of custody so that files can be verified later. Keep the storage separate from the systems under investigation where practical. Output: a written evidence handling procedure and a repository that a tester can open to see who has accessed what and when.
Write and approve the incident response plan
Document the six phases the requirement names: preparation, detection, analysis, containment, recovery and user response. For each phase, state the trigger, the responsible role, the procedure and the record it produces. Attach the contact roster, reporting channel, tracking template and evidence procedure as appendices. Output: a plan with a version number, a revision history and a signature from the accountable executive. Drafts do not satisfy the assessment objectives, so the approved version should be the one you show.
Configure detection for in-scope systems
Feed logs from in-scope hosts, network devices and cloud services into a monitoring platform, then enable rules that flag suspicious activity. Options include Wazuh with its built-in ruleset, or OpenSearch Security Analytics with Sigma rules, with alerts routed to the case system. Confirm each source is ingesting and each alert type reaches a responder. Output: a list of log sources, active detection rules and a sample alert that opened a case, all of which you can show an assessor.
Train roles and run a first exercise
Brief each named role on its duties, and record attendance and training materials. Then run a tabletop exercise that walks a plausible scenario through intake, triage, containment and recovery, using the real contacts and tools. Record gaps, assign owners and update the plan. Output: training records, an exercise report with dated findings, and a plan revision that reflects what the exercise exposed. Ask your consultant whether the exercise is designed to satisfy the separate testing requirement, IR.L2-3.6.3.

How open-source detection and case tools produce incident handling evidence

Open-source detection, case management and automation tools can produce much of the record an assessor will ask for under IR.L2-3.6.1, but no tool satisfies the requirement on its own. The requirement is met only when the organization has an operational incident-handling capability with a plan, named roles and proof that the plan works, and the tools are the systems that carry out and record that capability. An assessor will test the plan and the people first, then check whether the tool output matches what the plan says should happen.

A detection layer supplies the raw events for the preparation and detection activities. 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, writes matches to alerts.json and forwards them to the Wazuh indexer for review. OpenSearch Security Analytics (Apache-2.0) runs detectors against Sigma rules and records findings with rule, log type and severity. Before relying on either, confirm which rules cover the log sources in scope, who tunes them, and how alert volumes and triage decisions are documented, since an assessor will ask why a rule was enabled or suppressed.

DFIR-IRIS (LGPL-3.0-or-later) is the record of analysis, containment and recovery: each case holds assets, IOCs, tasks and logged evidence with SHA-256 verification, chain of custody and a full audit trail. Shuffle (AGPL-3.0-only) can carry out repeatable steps such as notifying the incident team or opening a ticket, but each workflow still needs an owner and a documented trigger. The decisions that matter most to an assessor, such as who declares an incident, who approves containment and when user response is communicated, must be written into the plan and visible in the case history. Confirm these decisions with your own incident response team before configuring any tool.

Which evidence artifacts pass an incident handling assessment

An assessor testing IR.L2-3.6.1 looks for records that show the incident-handling capability exists, is current, and was used. The artifacts below connect the plan to the people, channels, cases, evidence, training and exercises that prove it works, and each one needs a routine to stay accurate between assessments.

Approved incident response plan

The plan is the anchor document the assessor reads first. It should describe the preparation, detection, analysis, containment, recovery and user response activities the organization performs, name the roles that carry them out, and show the approval date and approver. Check that the plan matches how your systems are actually monitored and that it references the contingency plan. A draft or an unsigned version does not satisfy the requirement, so confirm the final approved version is the one assessors receive. Review it on a set schedule and after any significant change to systems or staffing.

Contact and escalation lists

Assessors look for named internal and external contacts, with a role, a primary and backup route, and the conditions that trigger escalation. External contacts often include legal counsel, forensic support, law enforcement liaison and the managed service provider. Stale phone numbers are a common finding, so record when each entry was last verified. Test a sample of the list during exercises and keep the verification dates alongside the list itself.

Reporting channel records

The Assessment Guide expects a way to report incidents, such as a monitored email address or phone line. Keep configuration evidence for that channel, including who receives messages, how after-hours reports are routed, and proof that the channel was tested. Record the mailbox or ticket queue owner and review access quarterly, since a channel nobody watches will not show up as evidence of a working capability.

Case records with timelines

Each incident, and each suspected incident the team dismissed, should have a case record that captures detection source, analysis notes, containment actions, recovery steps and the closure decision. A consolidated timeline shows the assessor that the steps happened in order and that the team followed the plan. In DFIR-IRIS, for example, each case keeps assets, indicators, tasks and evidence in one record with an audit trail, which makes this artifact easier to produce. Confirm that records are retained for as long as your policy requires.

Evidence logs with chain of custody

Where incident evidence is collected, the log should show what was collected, from which system, by whom, when, and where it is stored, along with hash values and each transfer of custody. Assessors check that the team decided where and how evidence is stored, as the Assessment Guide describes. Verify hashes periodically and confirm that storage access is restricted. Evidence logs that stop at collection, without custody transfers, tend to fail review.

Training curriculum and attendance records

Assessors test whether the people named in the plan were trained to carry out their roles. Keep the training curriculum and materials, plus attendance or completion records for responders, help desk staff and managers. Each time the plan or the tooling changes, update the curriculum and record who completed the revised material. Gaps between role changes and training completion are a frequent source of findings, so tie training dates to role assignments in your personnel records.

Exercise and test records

Tests of the incident-handling capability produce evidence that the plan works in practice. Record each exercise or real-incident review with its scenario, participants, the gaps found, the corrective actions and the owner and due date for each action. Closed actions need proof of completion. Schedule exercises on a fixed calendar so that the most recent record is never old enough to raise questions at assessment time.

What meeting IR.L2-3.6.1 costs in tooling, staff time and upkeep

This table lists each cost component of an incident-handling capability, who is paid for it, whether it is one-time or recurring, and what drives it up. Read it as a checklist for building a quote, since no fixed figures are published here and each cost depends on your environment and scope. The main takeaway is that open-source tools remove license spend, but planning, staffing, hosting and evidence upkeep still carry most of the cost.

Cost component	Who is paid or who does the work	One-time or recurring	Main cost drivers
Incident response plan writing	Internal security staff, or an implementation partner preparing the draft	One-time, then recurring review	Number of systems in scope, number of roles and contacts, and how many external parties the plan must name
Tooling licenses	Vendor for commercial SIEM, case management or SOAR products	Recurring if commercial	Data volume, number of users, and number of integrations. Self-hosted open-source tools have no license fee but still need hosting
Hosting and infrastructure for open-source tools	Your cloud provider, data center or internal IT team	Recurring	Log volume, retention period, storage tier, and whether the environment is in a CUI enclave
Detection and case engineering	Internal engineers or an implementation partner building detectors, rules and case templates	One-time build, then recurring tuning	Number of log sources, quality of log parsing, and volume of false positives during tuning
Incident response team training	Internal staff time, and any paid courses or vendor training	Recurring, usually tied to role changes	Team size, turnover, and whether training covers all user-response roles
Evidence upkeep	Internal staff maintaining case records, chain of custody and retained logs	Recurring	Number of incidents, retention rules, and how much evidence an assessor will sample
External exercise or independent review	Outside consultant, implementation partner or independent reviewer	Periodic, often tied to testing requirements	Scope of the review, plan complexity, and whether findings must be tracked to closure
Assessor sampling and assessment support	Independent assessor (C3PAO for Level 2 certification) and your internal staff for evidence requests	Per assessment cycle	Number of incident records sampled, documentation quality, and how many staff must answer questions

Who owns the capability, who can help build it, and what the assessor checks

Your organization owns the incident-handling capability under IR.L2-3.6.1. Leadership must name an accountable owner, and the people who will actually respond must agree to the plan, know their roles, and be able to make decisions during an incident. Ownership cannot be handed to a vendor, because the plan, the decisions and the sign-off are the facts an assessor will ask about. Expect the assessor to test whether the people named in the plan know what they are supposed to do.

Plan ownership: A named owner approves the incident response plan, reviews it on a set schedule, and records changes with dates and reasons.
Role assignment: Internal and external contacts, including legal, executive, human resources and any outside responders, are named with current phone numbers and email addresses.
Decision rights: The plan states who can isolate a system, take a service offline, or decide whether an event is an incident.
Training and records: Responders complete training on the plan and the attendance records are retained.
Sign-off: Management approves the final plan in a form that can be shown to an assessor.

Before an assessment, confirm that every named role holder can describe their part without reading the document.

Where incident handling programs fail assessment and how to close each gap

Most incident handling findings under IR.L2-3.6.1 come from a plan that exists on paper but cannot be shown to work. The gaps below share one root cause: the organization has written the capability but has not proven it, named its people, or kept evidence in a form an assessor will accept as final.

Plans never exercised

An incident response plan that has never been run gives an assessor nothing to test beyond the document itself. SP 800-171A asks for tests of the organization's incident-handling capability, so the plan must be walked through or simulated at least once. Check whether the file shows a date, the participants and the gaps found. Run a tabletop exercise against one realistic scenario, record what the team did, and update the plan from the results.

Unnamed external contacts

The CMMC Assessment Guide expects an incident-handling capability to identify internal and external contacts. Plans that say "contact legal" or "notify the vendor" without names, numbers and backups fail when an assessor asks who receives the call at 2 a.m. List each contact with role, primary and alternate channel, and an escalation owner, including the DoD reporting path linked to DFARS 252.204-7012. Confirm each entry in the last review cycle.

No evidence storage decision

The Assessment Guide expects the organization to decide where and how incident evidence is stored. Without that decision, evidence ends up in personal mailboxes, chat threads or local laptops, and the team cannot show integrity or access control. Write down the repository, who can read and write it, how evidence is hashed and how chain of custody is recorded. A case management tool such as DFIR-IRIS can hold this record, but the storage decision still belongs to the organization.

Detection not mapped to the plan

Alerts from SIEM and endpoint tools often arrive in a queue that the response plan never mentions. An assessor will look for a traceable path from a detection to a triage decision to an incident record. Map each detector or rule family to a severity, an owner and the plan section it triggers. Tools such as Wazuh and OpenSearch Security Analytics can produce the alerts, but the mapping document is what shows the capability is operational.

User response steps missing

The requirement covers user response activities, and many plans address only the security team. Users need short, specific instructions: how to report a suspicious email, what to avoid doing with an infected workstation, and who to call outside business hours. Test these steps with a sample of ordinary staff, not only administrators. Record the awareness material and the test results, since they support the training evidence the assessor reviews.

Drafts presented as final

An assessor scores a requirement as MET only when evidence is in final form. A plan labeled "v0.9 draft" or a training record with blank signature fields will fail even if the content is sound. Set a document control rule: each plan, contact list and training record carries an approval date, an approver and a version number. Remove superseded drafts from the evidence folder so the assessor sees one current version.

How long, costly and hard is it to meet 3.6.1 without outside help?

Can a defense contractor meet IR.L2-3.6.1 without outside help?

Yes, in principle. The organization owns its controls, so its own staff can write the incident response plan, define roles, run training and collect evidence. The harder question is whether the team can show that the capability works in practice. Assessors test 3.6.1 against seven assessment objectives in NIST SP 800-171A, and each one needs evidence in final form, not drafts. Staff who have not handled a real incident often find the plan is strong on paper and thin in records, such as training rosters, tracked incidents and documented analysis. Ask whether your team has someone who has run an incident response program before, and whether they can produce that evidence without help.

What drives the cost of meeting 3.6.1 in-house?

Most of the cost is staff time and tooling, not a fee. The main drivers are how many systems fall within the CUI boundary, whether logging and alerting already exist, how many people must be trained and how often, and whether the organization already runs a security operations function. Costs are both one-time (writing the plan, setting up tracking, building the first training) and recurring (keeping the plan current, training new staff, reviewing incidents, and keeping records). Open-source platforms can lower license spend, but they still need hosting, administration and tuning. When you request a quote from any outside firm, ask it to itemize one-time and recurring work, name who performs each task, and state which evidence it will prepare for your assessor.

How much effort does 3.6.1 take compared with the rest of Level 2?

The Level 2 requirements are set by NIST SP 800-171 Rev. 2, which the CMMC rule identifies as 110 requirements. Under the CMMC scoring methodology in 32 CFR 170.24, 3.6.1 carries 5 points, so it is one of the higher-weighted requirements and cannot be placed on a POA&M. That means it must be fully met before you can reach Conditional or Final Level 2 status. The effort is concentrated in a few deliverables: a documented plan, defined roles, a working reporting channel, incident tracking, evidence storage decisions, and training records. Because the work is tied to real operations, the effort rarely ends after the first assessment. Confirm the expected effort with your sponsor or assessor before committing staff.

How do 3.6.1, 3.6.2 and 3.6.3 differ in practice?

3.6.1 asks whether you have an operational incident-handling capability that covers preparation through user response. 3.6.2 asks whether you track and document incidents and report them to the right internal officials and external authorities, including the DoD reporting duty in DFARS 252.204-7012. 3.6.3 asks whether you test that capability, for example through exercises covering roles, escalation and business impact. In practice, 3.6.1 produces the plan, team and procedures; 3.6.2 produces the incident records and reporting chain; and 3.6.3 produces test plans and results that show the first two work. The same team often supports all three, so one set of records can serve more than one requirement, but each requirement is assessed separately. Confirm with your assessor how they expect evidence to be mapped.

Can we run a Level 2 self-assessment for 3.6.1 ourselves?

A Level 2 self-assessment is performed by the organization, so your own team can conduct it, and it is a valid route under the CMMC program for applicable contracts. The assessment checks each requirement against the objectives in NIST SP 800-171A and records a result. The self-assessor must be honest about whether each objective is satisfied with final evidence. Many teams find it useful to have an independent reviewer read the 3.6.1 evidence before the score is submitted, since a self-assessor who wrote the plan is not well placed to spot gaps in it. Whether a self-assessment is sufficient for your contract depends on the requirements in that contract, so confirm the required assessment level with the contracting officer or your sponsor.

What does the current CMMC phase status mean for 3.6.1 timing?

Current status affects when you need to be ready, not what 3.6.1 requires. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO's About CMMC page states that, as of 17 October 2026, implementation is paused in Phase 1 and may only require self-assessments at Levels 1 and 2, while the eCFR text of 32 CFR 170.3(e) still reflects the original schedule. Because these sources differ, confirm the current requirement for your contracts with your contracting officer and check the DoW CIO About CMMC page before setting dates.

What should internal staff provide if we bring in an implementation partner for 3.6.1?

An implementation partner can prepare systems, procedures and evidence, but your organization still owns the controls and makes the decisions. Internal staff should expect to provide the names and responsibilities of incident responders, executive decision makers, legal and communications contacts, and the systems in CUI scope. They should also approve the incident response plan, confirm reporting paths to designated officials, and decide where incident evidence is stored. Ask the partner for a written, fixed scope that lists the deliverables for 3.6.1 and the internal inputs it depends on. DeployOpen plans and implements self-hosted open-source platforms in your own infrastructure and prepares evidence for assessment, but it does not issue assessment results or certifications; an independent assessor does that.

How DeployOpen scopes, implements and prepares incident handling evidence

DeployOpen works under fixed-scope written agreements. Before any work starts, the scope, deliverables and timeline for IR.L2-3.6.1 are agreed in writing, and the quote follows from that scope. For this requirement, the scope should name the systems in the CUI boundary, the detection sources to be onboarded, the case management tool, the internal and external contacts who appear in the plan, and which of the six handling phases are covered by the engagement. The organization keeps ownership of its controls. DeployOpen's role is to prepare systems and evidence, and the organization's own leaders decide what the plan commits them to do.

Implementation uses self-hosted open-source tooling inside the client's own cloud accounts, data centers or air-gapped networks. A typical build, if the written scope includes it, connects log sources to a detection platform such as Wazuh or OpenSearch Security Analytics, routes alerts into DFIR-IRIS cases with evidence hashing and an audit trail, and uses Shuffle workflows to connect the SIEM, ticketing and notification steps. Confirm each product's current capabilities and license terms against its own documentation before you rely on them, and confirm that your assessor accepts the chosen tools as evidence sources.

DeployOpen also prepares the material an assessor will read. That means a mapping from each assessment objective in NIST SP 800-171A to the plan section, roles, training record or tool output that satisfies it, and records from tabletop or functional exercises that show the plan was tested. Ask for these deliverables by name in the written scope. DeployOpen does not issue audit reports, attestations or certifications. Independent assessors, and for Level 2 certification, C3PAOs authorized or accredited by The Cyber AB, make that determination, and the requirement is MET only when the evidence is in final form.