IR.L2-3.6.3 Incident response testing: requirements and evidence

What IR.L2-3.6.3 incident response testing requires in CMMC Level 2

IR.L2-3.6.3 asks the organization to test its incident response capability. Having a written incident response plan is not enough on its own. An assessor expects evidence that the people named in the plan can actually carry it out, that they know who decides what, and that the plan holds up when someone pushes on it. A plan that has never been exercised usually fails at the first hand-off: the named incident lead is unavailable, the escalation path points to a mailbox nobody checks, or the team has never agreed on when to call legal or law enforcement. A test is how those gaps surface before a real event does. Under the CMMC Level 2 model, this requirement maps to NIST SP 800-171 Rev. 2 requirement 3.6.3, and NIST SP 800-171A (June 2018) gives it a single assessment objective: the incident response capability is tested. That single objective is easy to state and easy to fail. Under 32 CFR 170.24, IR.L2-3.6.3 is worth 1 point, so it carries little weight in the score, but it is still a requirement that must be met to reach a full score. Confirm the current scoring and POA&M treatment against the eCFR text before you rely on it, because the program schedule has changed since the rule was published.

The hard part is usually one of two things. Either no exercise has been run at all, or an exercise was run but nothing was written down. Both fail the assessment. The assessment objects an assessor will ask for include the incident response test plan, the testing materials, the test results, and the incident response plan itself. The CMMC Assessment Guide expects a test to show what happens during an incident, who is responsible, what support legal, public affairs or other functions must provide, how resources are added, and how law enforcement is involved. An organization should decide its test cadence, assign an owner for each exercise, and keep a dated record of scenario, participants, decisions, gaps and corrective actions. A practical first step is to pick one realistic scenario that touches the organization's CUI environment, such as a suspected credential compromise on a system that stores controlled data, and walk it through a tabletop with the people the plan names. Record who made each decision and how long it took. Then track each gap to a closed corrective action. Ask any implementation partner to prepare the test plan, scenario library and evidence templates, and keep the scoring and final determination with your own assessor.

Which systems, teams and third parties a CMMC incident response test must cover

A test of IR.L2-3.6.3 is only as wide as its scope. The decisions below determine which systems, people and outside parties an exercise must include, and each one changes what the test has to prove. Settle them in writing before the test plan is drafted, because assessors will compare the plan against the actual CUI environment.

Define the CUI environment and boundary

Start by listing every system that stores, processes or transmits CUI, plus the security tools that monitor them. The boundary decides which assets a scenario may touch, such as the file repository, identity provider, endpoint agents and log pipeline. Check that the test plan names these components and that the boundary diagram in the system security plan matches what the exercise covers. A scenario that stops at the boundary leaves the most likely entry points untested.

Assign roles across IT and security

Name the people who detect, triage, contain and recover, and confirm each one has the access and authority to act during the exercise. Include system administrators, the security operations lead and the owner of each CUI system. Assessors look for evidence that the roles in the plan were exercised, not just listed, so record who made each decision and when. Gaps in after-hours coverage are a common finding.

Include legal and public affairs

Decide whether counsel and public affairs take part in the exercise, and who speaks for the organization if an incident becomes public. Their involvement changes the test because notification decisions, privilege and messaging each have timing constraints. Confirm that the test covers how contract reporting duties are assessed, including the 72-hour reporting duty in DFARS 252.204-7012 linked to the incident reporting requirement.

Cover executive decision points

Identify the executives who must approve containment actions that stop business operations, such as taking a production system offline or isolating a contract facility. Build at least one scenario where the decision is required and time-boxed. The test then shows whether escalation reaches the right authority quickly enough to act, which is the point IR.L2-3.6.3 asks the organization to validate.

Bring in managed security providers

If a managed security service provider monitors logs or runs the security tools, its staff belong in the exercise with the same escalation paths as internal staff. Confirm in the service contract who may take containment actions, how quickly the provider must respond and where its analysts record their work. Ensure the provider's records can be produced as test results during an assessment.

Account for cloud and outside counsel

When CUI runs in a cloud environment, the cloud provider's shared responsibility split determines which logs, snapshots and support channels the organization can use during a response. Test whether the team can obtain those artifacts and whether outside counsel can be reached. Confirm the provider's notification terms and the counsel engagement terms before the exercise, so the test measures the organization's process rather than contract delays.

How a CMMC assessor tests incident response testing

This table walks through each assessment object an assessor reviews for IR.L2-3.6.3, the evidence to have ready, how the assessor checks it and the findings that commonly come up. Read it as a preparation checklist: the assessor needs to see a plan, a test, results and follow-up, not just a document that says testing happens.

Assessment object	Evidence the assessor requests	How the assessor checks it	Common findings
Assessment objective (single objective in NIST SP 800-171A)	Records showing the incident response capability has been tested, with dates, scope and participants	Confirms at least one test was run and that the record matches the stated capability, not a plan to test later	No test has ever been run, or the only record is a calendar entry or a plan
Incident response test plan	Written test plan covering objectives, scenarios, roles, success criteria and schedule	Checks that the plan names the scenarios tested and that its scope matches the incident response plan	Plan is generic, has no scenarios, or was approved after the test it describes
Testing material	Scenario scripts, injects, tabletop slides, simulation inputs and participant lists	Compares the material with the plan and confirms it covers roles, escalation, legal and law enforcement involvement and business impact	Scenarios do not reach escalation or external notification steps, so those parts were never exercised
Test results	Exercise reports, timelines, observations, decisions made and who attended	Traces each objective in the plan to a documented result, pass or fail, with the reasons	Results are missing, say only that the test went well, or list no gaps at all
Follow-up on gaps	Corrective action items, owners, due dates and evidence that changes were made	Looks for a link from each gap in the results to a tracked fix and a retest or later exercise	Results with no follow-up, or actions that stay open with no owner or date
Incident response plan and contingency plan	Current versions of both plans, with revision history and approvals	Checks that the plans were updated after the test and that the tested procedures match the written steps	Plan revised without reference to test findings, or the tested steps differ from the written ones
Procedures for incident response and contingency plan testing	Documented procedure for how tests are scheduled, run, reviewed and recorded	Confirms the procedure is followed in practice by comparing it with the test records	Procedure exists but the recorded tests were run differently, or the procedure was never followed
Personnel involved in testing	Roster of participants, roles held during the test and training records for those roles	Matches responders named in the test with the roles in the plan and checks that they had access to the procedures	Test used the same few people, or named roles were filled by staff who were not trained for them

How to build an incident response test program that passes assessment

The sequence turns the IR.L2-3.6.3 test expectation into a planned, documented and repeatable exercise cycle, so an assessor can see that the incident response capability was tested, what it exposed, and what changed as a result.

Set test objectives from the assessment topics
Start by writing down what the exercise must prove. The CMMC Assessment Guide Level 2 expects a test to address what happens during an incident, who is responsible, what support is needed from legal, public affairs or other functions, how resources are added, and how law enforcement is involved. Assign an owner, usually the incident response lead or CISO, to sign off the objectives. The output is a short objectives statement that maps each topic to a question the exercise must answer.
Write the incident response test plan
Turn the objectives into a written test plan that names the scenario, participants, roles being exercised, injects, timing, facilitator, observers and success criteria. Reference the incident response plan and any contingency plan the test will exercise, since these are assessment objects for 3.6.3 under NIST SP 800-171A. The plan is complete when a person outside the team could run the exercise from it and an assessor could trace each objective to the test steps.
Run a tabletop or functional exercise
Run the exercise as a discussion-based tabletop or as a hands-on functional test, depending on what the objectives require. A tabletop walks participants through the scenario and tests decisions, escalation and communication. A functional exercise also exercises tools, access and recovery steps. Include legal, public affairs and law enforcement liaison roles where the objectives call for them, even if those participants only role-play. The output is a facilitator's log showing who acted, when, and what decisions were made.
Record results and gaps
Document what worked and what failed against each objective. Capture the test materials, attendance, injects delivered, decisions taken, delays in escalation, unclear responsibilities and missing contacts. Keep the results in final form with dates and named participants, because an assessor will not accept drafts as evidence. The output is a signed test report that lists each gap with its severity and the objective it affects.
Track corrective actions to closure
Convert each gap into a corrective action with an owner, a target and a status. Update the incident response plan, contact lists, escalation paths or tooling as needed, and keep the revised versions with change records. Where a gap cannot be closed promptly, record it in the plan of action and milestones process rather than leaving it undocumented. The check is that every gap has a tracked action and that the plan changes are traceable to specific findings.
Repeat the test on a defined cycle
Set a testing cycle in the incident response policy and confirm the required frequency with your assessor or contract requirements, since this page does not supply a fixed interval. Repeat the sequence with new scenarios that cover gaps from earlier tests and changes to systems, staff or suppliers. Each cycle should show the earlier corrective actions were verified. The output is a dated test history that shows the capability is tested and improved over time, which is what an assessor looks for when they test IR.L2-3.6.3.

What a credible exercise scenario includes

A credible IR.L2-3.6.3 exercise starts from a scenario that the organization could plausibly face and that touches the CUI environment directly. Build the injects around a suspected compromise of a system that stores or processes CUI, such as an engineering file share or a system security plan repository, and let the exercise team decide how the incident unfolds. The scenario should force decisions on who declares the incident, who owns containment for the CUI enclave, who can authorize taking a system offline, and how the response team pulls in IT, legal, public affairs and executive leadership. Each inject should have an expected decision and a named owner, so the facilitator can tell whether the plan worked or whether people improvised around it. The reporting path deserves its own timed branch. Ask whether the team can determine, within the window its contract and DFARS 252.204-7012 obligations require, whether the incident affects covered defense information, and who makes that call. The sibling reporting topic covers the records and reporting chain in detail, so here the exercise should test whether those records exist and whether the people named in the chain know their steps. Confirm the current reporting timing against the clause text and your contracting officer's expectations before you write the timer into the scenario, since the exact window is not restated on this page. Also include a law enforcement branch, such as a ransomware note or a suspected insider, so the team practices deciding when to involve authorities and how that choice affects evidence handling.

A scenario that nobody can fail is weak evidence. If every inject has an obvious answer, every participant completes every step, and the exercise ends with the business back online, the test shows only that people are willing to attend. Assessors look for evidence that the capability was tested and that results were compared against the plan, so the scenario must include conditions that can break the plan. Examples include a primary escalation contact who is unavailable, a backup communication channel that is also down, a business owner who disputes the impact estimate, or a vendor who cannot be reached during the containment window. Record each failure, the time it appeared, and the corrective action assigned. The output of a credible exercise is a written after-action report with test results, identified gaps, owners and due dates, and updates to the incident response plan where the test exposed them. Keep the test plan, the injects, the participant list and the report together so they can be shown to an assessor in final form. Ask any external facilitator or consultant to document their role clearly, because the organization owns the test and its conclusions, and only the independent assessor decides whether the evidence meets the practice.

Evidence that proves incident response testing to an assessor

An assessor testing IR.L2-3.6.3 looks for a paper trail that shows the organization tested its incident response capability, learned from the test, and fixed what it found. The cards below cover the artifacts that make up that trail and the habits that keep them current between assessments.

Dated test plan

The test plan states the objective, scope, date, participants and success criteria for each exercise. It is the first object an assessor asks for, because it shows the test was planned rather than improvised. Check that the plan names the incident response plan and contingency plan it validates, and that it is approved and dated before the exercise runs. A plan written after the exercise will not satisfy the assessor.

Scenario and injects

The scenario describes the simulated incident, and the injects are the timed events that push the team through decisions. Good injects test roles, escalation, legal and law enforcement involvement, and business impact, as the CMMC assessment guide expects. Keep the scenario file and the inject schedule together so an assessor can see what was tested and when each decision point arrived.

Attendance and role assignments

A roster with names, titles and the role each person played shows who was responsible during the test. Record who joined from legal, public affairs and other functions, because the assessment expects those supporting roles to be exercised. Gaps here, such as an escalation contact who never attended, are findings that the test log should also capture.

Test log and minutes

The log records what happened in order, including timestamps, decisions, delays and who made each call. It is the record that shows the response capability was tested rather than described. Write the log during the exercise or immediately afterward, and mark it final once reviewed. An assessor will treat an unsigned or undated log with caution.

Findings and corrective actions

Each gap the exercise exposed becomes a finding with a named owner, a corrective action and a closure date. Assessors look for this loop because it proves the test had consequences. Track findings in the same system as other remediation work so an assessor can trace a finding to its closure. Open findings past their dates should be visible and explained.

Updated plan versions and contingency link

Version history for the incident response plan shows that each finding was reflected in the document. Confirm that the contingency plan the test touched is updated at the same time and that the two documents reference each other. Keep prior versions, so an assessor can see the plan changed over time and that the current version is the one tested.

What meeting IR.L2-3.6.3 costs in money and effort

This table breaks down the cost components of running incident response testing for IR.L2-3.6.3, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to shape your quote requests, since no supplied figure sets a price for any component.

Cost component	Who is paid or who spends time	One-time or recurring	What drives the cost and what to request in a quote
Exercise planning and test plan	Internal IR lead and compliance staff, or an outside facilitator under a fixed-scope agreement	One-time per plan, then recurring when the plan changes	Scope of systems, number of scenarios and the test plan you must retain as an assessment object. Ask for the planning hours and the written test plan as deliverables.
Facilitator time for running exercises	Internal facilitator or an external firm billing per engagement	Recurring, tied to each test cycle	Number of scenarios, participants and whether tabletop or technical tests are included. Ask which roles the facilitator covers and how results are documented.
Staff time for participants	Security, IT operations, management, legal and communications staff who take part in the exercise	Recurring, usually the largest internal effort	Headcount and how many functions must attend to test roles, escalation and business impact. Plan for their time away from regular work.
Legal and public affairs involvement	Internal counsel and communications staff, or outside counsel if retained	Recurring per exercise	Whether the scenario includes legal reporting, contractual notice or law enforcement contact. Ask your counsel to confirm which steps they will rehearse.
Case management and evidence tooling	Software licensing or self-hosted platform effort for an open-source tool such as DFIR-IRIS	Setup is one-time, hosting and upkeep recur	Hosting, integration with alert sources, storage for test records and administrator time. Confirm license terms and hosting responsibility before purchase.
Independent review or testing services	Outside reviewers or testers paid to challenge the plan or observe results	Usually recurring, optional	Depth of review, number of test cycles and whether the reviewer also helps prepare evidence. Ask for a written scope that keeps the assessor independent of the preparation work.
Remediation of exercise findings	Internal engineering and process owners, or an implementation partner for technical fixes	Recurring after each cycle	Number and severity of gaps the exercise exposes. Ask the partner to separate fixes to tooling from changes to the plan and training.
Assessment support and evidence retention	Internal compliance staff, with optional help from an outside party to organize records	Recurring, aligned with assessment cycles	How many records must be kept in final form for the assessor to review. Confirm which artifacts the assessment team will ask for before work starts.

Who owns the test, who can help, and where the assessor stops

The organization owns its controls, and that includes the incident response capability that IR.L2-3.6.3 tests. No partner or assessor can decide who is on the incident response team, who has authority to take a system offline, or whether a business risk is accepted. Those decisions belong to leadership, and the test is only useful if the people who would make them in a real event take part.

Plan ownership: Leadership approves the incident response plan and the contingency plan, and the security function keeps them current after each exercise.
Role assignment: Named individuals hold incident commander, technical, legal, communications and executive roles, with alternates for absences.
Escalation authority: The organization sets the thresholds at which an event moves to executive decision makers and to any external reporting chain.
Participation: Legal counsel, public affairs and business owners attend the exercise, since the assessment looks for their involvement, not only the security team's.
Remediation: The organization assigns owners and dates to every gap the exercise exposes and tracks them to closure.

Before you engage anyone, confirm that your own leadership has agreed on who owns each decision in the test.

How DFIR-IRIS supports test records and follow-up

DFIR-IRIS can hold an incident response exercise as a case, so the test record, the evidence and the corrective tasks sit in one place. A case in DFIR-IRIS keeps assets, indicators, tasks and evidence together with a full audit trail, which lets an assessor see what the team did during the exercise, when it did it and who did it. For IR.L2-3.6.3, that matters because the single assessment objective asks whether the capability is tested, and the test plan, testing material and test results are the objects a C3PAO will request. Teams can log exercise injects as alerts or tasks, attach the scenario and outcomes as evidence, and keep the record intact after the exercise closes.

The case timeline is the part most useful for testing. DFIR-IRIS builds a consolidated investigation timeline from case activity, so the team can compare what the scenario planned against what responders actually did, including gaps in escalation, late notifications to legal or law enforcement contacts, and delays in resource requests. Each gap can become a task linked to the exercise case, and the task status and closure notes stay attached to the original finding. Evidence logging with SHA-256 verification and chain of custody is available for exercise artifacts too, which helps when a test record must be shown as unaltered. Reports generated from case data can then serve as the written test results, provided the content is reviewed and approved by the organization.

DFIR-IRIS supports the evidence but does not design or run the exercise, and it does not replace the incident response plan, the roles, or the decisions about scope and escalation. The organization must still define the exercise objectives, select participants, and decide what counts as a passed test. Before adopting it for this purpose, confirm the fit against your environment: how alerts will be ingested from your SIEM or EDR, who holds administrator rights over exercise cases, how records will be retained, and whether your assessor accepts exported reports as test results. The DFIR-IRIS documentation is the right starting point for checking those features against your own deployment.

Why incident response tests fail assessment

Does a tabletop exercise count if no full test happened during the assessment period?

A tabletop exercise can count, but only if it is actually run, documented and tied to the plan. The assessment objective for IR.L2-3.6.3 is that the incident response capability is tested, so an assessor will ask for a test plan, testing material and results from a defined period. A plan that says tests will happen later, or a calendar entry with no record of what was discussed, leaves the requirement unmet. Close this gap by scheduling at least one exercise in the assessment period, assigning an owner, and keeping the invitation list, scenario, attendance and minutes together. Confirm your exercise frequency and scope with your assessor and your own contract requirements before you set the calendar.

What happens when a test ran but nobody wrote down the results?

An undocumented test is treated as a test that did not happen. Assessors look for test results, not recollections of a good discussion. Results should record the scenario, the participants, the decisions made, the time each step took, the gaps identified and the owner for each corrective action. Store the record in the same place as your incident response plan, under version control, so it stays in final form. Draft notes that were never finalized do not satisfy the evidence expectation for a MET finding.

Why does an assessor flag the incident response plan when findings never led to updates?

Testing is only useful if it changes the plan. When a test exposes a missing contact, an unclear escalation step or a tool nobody can access, the plan should be revised and the revision dated. Assessors compare test findings with the plan version in effect afterward. If the same gap appears in two exercises, the finding looks like a control that is tested but not maintained. Close this by keeping a findings register linked to the plan, assigning each item a due date, and recording the plan version that closed it.

What goes wrong when legal and law enforcement never appear in the test scenario?

The test does not reflect what an incident actually requires. The CMMC Assessment Guide for Level 2 expects a test to address what support is needed from legal, public affairs or other functions and how law enforcement is involved. A scenario that covers only technical containment skips decisions about privilege, notification duties, evidence handling and whether to contact authorities. Close this by including counsel or a designated legal contact in at least one scenario, walking through when law enforcement is engaged, and recording who decided and on what basis. Confirm the reporting thresholds that apply to your contracts with counsel.

Can business impact be left out of an incident response test?

Leaving business impact out is a common reason tests look incomplete. A test should show how an incident affects operations, which systems or contracts are at risk and when leadership must decide on trade-offs, such as taking a system offline. Assessors will expect the scenario to cover who is responsible for those decisions and how resources are added during the response. Close this gap by writing the scenario around a named business process, asking the business owner to attend, and recording the decisions and the time they took. Ask your team to confirm the impact criteria they use before the exercise.

How can a team with limited staff run a test that an assessor will accept?

A small team can run a credible test by keeping the scope narrow and the paperwork complete. Choose one realistic scenario, such as a compromised administrator account, and walk through the plan step by step with the people who would respond. Use a simple checklist for objectives, roles, escalation, legal and business questions, and results. Self-assessments and third-party assessments both require evidence in final form, so the record matters as much as the exercise. Whether you run the exercise yourself or bring in outside help is a scope decision, and the written scope should state which parts your staff owns and which parts a partner prepares.

Does DeployOpen run incident response tests for a CMMC environment?

DeployOpen can help prepare the testing capability inside your own infrastructure, but it does not perform the assessment or issue findings. Under its fixed-scope engagements, DeployOpen can plan exercise material, prepare case-tracking systems for evidence, and document results for your team to review. For example, a case-management platform such as DFIR-IRIS keeps incident records, evidence and reports in one audit trail, which can support the test record your assessor will ask for. Scope, deliverables and timelines are agreed in writing before work starts, and any quote follows from that written scope. Your assessor, not DeployOpen, decides whether the requirement is met.

How DeployOpen prepares incident response testing evidence

DeployOpen's part in IR.L2-3.6.3 is to prepare the test and the records that prove it happened, while the organization owns its incident response capability and the independent assessor decides whether the requirement is met. Before any exercise runs, DeployOpen scopes the test in writing: which incident response plan and contingency plan sections are in scope, which systems and teams take part, whether the exercise is a tabletop, a functional drill or a combination, and what the organization wants to learn. The written scope also names the people who must be involved, including legal counsel, public affairs and the contact for law enforcement, so the exercise can test those handoffs rather than assume them.

In the client's own environment, DeployOpen designs and facilitates the exercise scenarios, injects events on a schedule agreed in advance, and records decisions as they happen. The test should show who is responsible at each stage, how escalation moves, what support is requested from legal or public affairs, how additional resources are brought in, and how business impact is judged. DeployOpen keeps the test plan, testing material and results in one controlled record set, and it can set up case tracking in a self-hosted platform such as DFIR-IRIS so that exercise timelines, tasks and evidence sit in the same audit trail as the test. Confirm with your own team which evidence form your assessor expects before the exercise starts.

After the exercise, DeployOpen supports the findings review and remediation: gaps are logged with owners and dates, plan updates are drafted for the client to approve, and a follow-up exercise can confirm that fixes work. Clients should confirm three things before signing: that the scope names the people and decisions the assessor will look for, that the final plan, results and remediation records are delivered in a form the client controls, and that the client's own approval steps are built into the timeline. DeployOpen does not issue assessment reports, attestations or certifications. Self-assessment scoring and any certification assessment are performed by the organization and by independent assessors, and the requirement is met only on the assessor's review of the evidence.

IR.L2-3.6.3 Incident response testing