What IR.L2-3.6.3 Actually Requires
IR.L2-3.6.3 reads: "Test the organizational incident response capability." That is the entire requirement text. One SPRS point attaches to it, and assessors treat it as a test method assessment. They look for documented evidence that testing occurred, not just a policy that says testing will occur.
The CMMC Assessment Guide specifies that assessment for 3.6.3 includes examining IR test plans, examining the results of IR tests, interviewing personnel responsible for incident response, and testing to verify that IR capability functions as described. A tabletop exercise is the most common way small DIB contractors satisfy this requirement. It is low-cost, organizationally feasible, and produces the documentation an assessor needs. But only if it is run and recorded correctly.
The requirement is deliberately broad. It does not specify tabletop exercises, functional drills, or full-scale simulations. Any of those formats can satisfy it. What matters is that testing happened, was documented with sufficient detail, and produced findings that the organization addressed.
What Assessors Look For
When a C3PAO assessor evaluates your IR testing capability, they are looking at four things: whether testing occurred, whether it was documented, whether it involved the right people, and whether the organization learned something from it and acted on the findings.
| What Assessors Check | What Satisfies It | What Fails |
|---|---|---|
| Evidence testing occurred | Dated after-action report or exercise record with scenario description | A calendar invite or email thread with no formal documentation |
| Right personnel involved | Names and roles of participants matching roles in the IR plan | Only IT staff present; no IR team lead, legal, or management representation |
| Realistic scenario | Scenario that tests the specific procedures in your IR plan (DIBNet reporting, forensic imaging, isolation) | Generic "what would you do if there was a breach" discussion with no defined inject points |
| Findings documented | At least one gap, confusion point, or improvement area documented in the after-action report | After-action report that concludes all procedures functioned correctly with no gaps identified |
| Corrective actions taken | Each finding mapped to a corrective action with an owner and target date | Findings listed with no corresponding remediation plan or follow-up |
| Recurrence / frequency | Exercise history showing varied scenarios across multiple cycles | Same scenario repeated annually for three years with no variation |
Documentation Requirements
The after-action report is your primary evidence artifact for IR.L2-3.6.3. It does not need to be elaborate, but it must contain specific elements that allow an assessor to confirm what happened and what the organization did with the results.
| Element | What to Include |
|---|---|
| Exercise date and type | Date conducted, format (tabletop, functional drill, full-scale), duration |
| Scenario description | The specific incident scenario used, with enough detail that a reviewer can understand what was tested |
| Objectives | What procedures the exercise was designed to test (detection, DIBNet reporting process, containment, forensic imaging, etc.) |
| Participants and roles | Names and titles of everyone who participated, including the facilitator |
| Inject log | The sequence of scenario developments presented during the exercise and how the team responded at each step |
| Findings | Specific gaps, confusion points, procedural failures, or improvement areas surfaced by the exercise |
| Corrective actions | For each finding: what change will be made, who owns it, and target completion date |
| IR plan update status | Whether the exercise triggered any updates to the IR plan, and if so, when those updates will be completed |
| Next exercise date | Scheduled date for the next exercise. This demonstrates that testing is an ongoing program, not a one-time event. |
Five Tabletop Scenarios for DIB Contractors
The scenarios below are written specifically for small defense contractors handling CUI. Each targets a realistic threat vector for the DIB and exercises the procedures most commonly tested during CMMC assessments: DIBNet reporting timing, forensic imaging obligations, and containment decisions.
Scenario 1 — Ransomware on a CUI Workstation
At 7:42 AM, an engineer reports that files on their workstation are returning errors and a ransom note has appeared on the desktop. The system is used daily to receive and work on contract deliverables that contain CUI. The engineer's account is also mapped to a shared network drive used by three other project team members.
Key inject points: When does the 72-hour DIBNet reporting clock start? Who makes the call to isolate the workstation before forensic imaging is complete? Is the shared drive also considered compromised? Who notifies the contracting officer? How do you determine whether CUI was exfiltrated before encryption occurred?
Procedures to test: Incident detection and severity classification, system isolation vs. forensic preservation sequence, DIBNet reporting trigger determination, internal notification chain, CUI exposure scoping, evidence preservation obligations under DFARS 252.204-7012.
Scenario 2 — Phishing Credential Compromise
An employee receives an email that appears to be from a prime contractor, clicks a link, and enters their credentials into a spoofed login page. The employee reports it to IT 36 hours later after noticing account activity they did not initiate. Logs show two successful authentications from an unrecognized IP address in a foreign country during the gap window.
Key inject points: Is this a reportable incident under DFARS 252.204-7012? What systems did the compromised account have access to, and how quickly can that be determined? What is the forensic imaging obligation when the compromise is account-based rather than endpoint-based? How do you handle the 36-hour reporting delay internally?
Procedures to test: Account compromise detection, access scope review, log analysis procedures, MFA coverage gaps, internal escalation timeline, DIBNet reporting eligibility decision process, communication with affected program offices.
Scenario 3 — Insider Data Exfiltration
A departing employee with two weeks remaining on their notice period is flagged by your SIEM with an alert showing an unusually large number of file accesses to CUI folders over two days, followed by a large upload to a personal cloud storage domain. The employee's manager says the employee has been acting normally and denies any knowledge of the activity.
Key inject points: How do you preserve evidence without tipping off the employee? What is your authority to disable their account before the investigation is complete? Does this trigger DIBNet reporting? Who is responsible for interviewing the employee, and should HR or legal be involved before that happens? What if the upload destination cannot be confirmed as personal storage?
Procedures to test: Insider threat detection response, evidence preservation without system modification, legal and HR coordination procedures, account privilege review, CUI data loss determination, reporting trigger evaluation.
Scenario 4 — Unpatched Vulnerability Actively Exploited
CISA issues an emergency directive for a critical vulnerability in a web application your organization runs internally. Your vulnerability scanner confirms the application is running the affected version. Within 24 hours of the CISA alert, threat intelligence indicates active exploitation of this vulnerability in the wild. You have not yet patched the system because it requires a maintenance window coordination with two other teams.
Key inject points: At what point does a known-unpatched system with confirmed active exploitation in the wild become a reportable incident? What interim mitigations can be applied while the patch is scheduled? Who has authority to take the system offline if exploitation is confirmed on your instance? What documentation is required before and after the maintenance window?
Procedures to test: Vulnerability-to-incident escalation criteria, emergency change management procedures, interim risk acceptance documentation, SIEM monitoring of exploitation indicators, coordinated maintenance execution, post-patch verification.
Scenario 5 — Third-Party Contractor Breach
A subcontractor that has remote access to your CUI systems notifies you that they have suffered a ransomware attack. They are not yet able to confirm whether the attacker accessed your systems through their remote access credentials, but they have shut down their operations and their access credentials to your environment are still active.
Key inject points: Do you revoke their access immediately before you have confirmation of lateral movement into your environment? If you do revoke access and it turns out there was no breach, what are the contractual implications? At what point does this become your DIBNet reporting obligation vs. solely theirs? How do you scope your log review to determine whether their credentials were used against your systems?
Procedures to test: Third-party access revocation procedures, supply chain incident response coordination, log review for external credential activity, internal scope determination, DIBNet reporting responsibility analysis, contractual notification obligations.
Running the Exercise
A tabletop exercise is a facilitated discussion, not a technical drill. Participants talk through their responses to a scenario rather than executing actual procedures. The facilitator presents the scenario in stages (injects) and asks the group to walk through how they would respond at each decision point. The goal is to surface gaps in the plan, ambiguities in roles, and missing steps before a real incident forces you to discover them under pressure.
Before the Exercise
Choose a scenario relevant to your environment and threat model. A small engineering firm handling CAD files on a classified program has different risk exposure than an IT services contractor managing DoD cloud infrastructure. The scenario should test the procedures most likely to be stressed in an actual incident at your organization, not the most dramatic scenario you can imagine.
Define the objectives in writing before the exercise begins. What specific procedures are you testing? Which IR plan sections does this scenario touch? Having written objectives prevents the exercise from drifting into a general security discussion and gives the after-action report a baseline for evaluating findings against intent.
Invite the right people. At minimum: the incident commander identified in your IR plan, their designated backup, whoever handles external reporting (DIBNet), and whoever makes containment and isolation decisions. Including legal or HR for scenarios involving insider threats or employee data is appropriate and demonstrates maturity to an assessor.
During the Exercise
The facilitator presents each inject, then pauses for discussion. The facilitator should not accept "we would check the IR plan" as a complete answer. Probe into who specifically does that check, how long it takes, what happens if that person is unavailable, and what the IR plan actually says on that point. Those follow-up questions are where gaps appear.
Assign a notetaker separate from the facilitator. The notetaker captures the decisions made, the disagreements surfaced, the procedural questions that came up without clear answers, and the specific plan sections that participants referenced (or could not locate). That record becomes the basis for the after-action report.
After the Exercise
Write the after-action report within five business days while the discussion is still fresh. The report does not need to be long, but it needs to be specific. "Team was unclear on escalation threshold for DIBNet reporting" is useful. "Communication gaps were identified" is not. Each finding should be specific enough that a corrective action can be written against it.
For each finding, assign an owner and a target date. Update your IR plan where the exercise exposed deficiencies. Schedule the next exercise date before distributing the report. This closes the loop and keeps the testing program continuous rather than a one-time compliance event.
Exercise Types and When to Use Them
Tabletop exercises are not the only way to satisfy IR.L2-3.6.3. As your IR program matures, incorporating other exercise types produces stronger evidence and a more capable response team.
| Type | Description | Assessor Weight | Best For |
|---|---|---|---|
| Tabletop | Facilitated discussion of a scenario. Participants describe what they would do at each decision point. No live systems involved. | Satisfies 3.6.3. Most common format at small contractors. | Annual baseline requirement, onboarding new IR team members, testing a recently updated IR plan |
| Functional drill | Team members execute specific procedures in a controlled environment: running the DIBNet portal submission process using test data, practicing forensic imaging on a designated test system, executing the account lockout and access revocation workflow. | Stronger evidence than tabletop alone. Demonstrates operational readiness rather than theoretical knowledge. | Testing specific high-stakes procedures like DIBNet reporting and forensic preservation, where execution failures during a real incident have regulatory consequences |
| Post-incident review | Documented lessons-learned review of an actual security incident. Covers what happened, how the team responded, what worked, what failed, and what changes are being made. | Typically the most compelling evidence for assessors. Demonstrates real-world capability. | Any incident that triggered IR plan activation, even minor ones. Every documented real-incident review strengthens your IR evidence package. |
| Red team / penetration test with IR component | External red team exercises your detection and response capability under realistic adversarial conditions. Your IR team responds as though the activity is a real incident. | Strong, but not required and often not feasible for small contractors. Significantly more costly than a tabletop. | Mature organizations wanting to test detection capability, not just response procedures. Combined with a standard tabletop, produces the most comprehensive evidence package. |
Common Mistakes That Create Assessment Risk
The following patterns come up repeatedly in CMMC assessments where IR.L2-3.6.3 receives a finding of "Not Met" or where assessors downgrade a "Met" determination after interviews surface problems with how testing was actually conducted.
| Mistake | Why It Creates Risk |
|---|---|
| Documenting the exercise as a meeting with no formal output | A calendar entry or email summary is not an after-action report. Assessors request documentation; a meeting invite does not satisfy examination of IR test results. |
| Excluding the actual IR team from the exercise | If the people who participated in the tabletop do not match the roles defined in the IR plan, the exercise does not test your IR capability. It tests a hypothetical one. Assessors will ask who attended and verify those people are the IR plan roles. |
| Using the same scenario every year | Scenario repetition signals that the exercise is a checkbox, not a genuine test. Assessors look for scenario diversity across the exercise history. Rotating through ransomware, credential compromise, insider threat, and supply chain scenarios over a two to three year period is defensible. |
| Not testing the DIBNet reporting process specifically | The 72-hour reporting obligation under DFARS 252.204-7012 is the most time-critical IR procedure a DIB contractor has. If your tabletop scenario never triggers the DIBNet reporting decision point, you have not tested the most assessor-visible part of your IR capability. |
| After-action report that shows no findings | As noted earlier: assessors treat zero findings as a signal that the exercise was not taken seriously. Budget time in your exercise for the facilitator to probe answers until gaps surface. They are there. You want to find them before your assessor does. |
| No follow-through on corrective actions | An assessor who sees findings from three years of exercises with no corresponding updates to the IR plan or corrective action closure records will conclude that the exercise program is theater. The exercises must produce real changes or they do not satisfy the spirit of 3.6.3. |
How 1TEN Helps
1TEN's IR Exercises module is the dedicated record-keeping system for tabletop exercises and functional drills. Every exercise record captures the date, type, scenario description, facilitator, participants and their roles, objectives, inject log, findings, corrective actions with owners and target dates, and next scheduled exercise date.
When a C3PAO assessor requests evidence for IR.L2-3.6.3, you pull the exercise history from the module. The records are structured to match exactly what an assessor looks for when examining IR test results under the CMMC Assessment Guide. There is no searching through shared drives, email threads, or network folders for documentation that may or may not exist.
The module also surfaces the next scheduled exercise date in the Compliance Calendar, ensuring testing stays on a continuous schedule rather than being forgotten until the week before an assessment. 1TEN tracks exercise history across all records and flags to users when scenario diversity is low, helping you rotate through the scenario types that assessors expect to see represented.
Frequently Asked Questions
How often do I need to run a tabletop exercise for CMMC?
NIST SP 800-171 and the CMMC Assessment Guide do not prescribe a specific frequency. Assessors expect at least annual testing. Running two exercises per year with different scenarios produces stronger evidence and is more defensible when an assessor asks about scenario diversity.
Can a tabletop exercise satisfy IR.L2-3.6.3 by itself?
Yes, a properly documented tabletop exercise satisfies IR.L2-3.6.3 as the primary testing method. The documentation must include the date, participants and their roles, scenario used, procedures tested, findings or gaps identified, and corrective actions planned. An exercise with no documented findings is a red flag for assessors.
Do we need an outside facilitator to run a tabletop exercise?
No. An internal facilitator is acceptable. The assessor cares about documentation quality and what the exercise produced, not who ran it. Using an external facilitator like an RP or MSSP can add credibility and often surfaces gaps that internal staff miss, but it is not required.
What happens if our tabletop exercise reveals a gap in our IR plan?
Finding gaps is the point. Document them in your after-action report and create a POA&M item or corrective action record addressing each one. Assessors expect exercises to produce findings. An exercise that concludes "everything worked fine" with no gaps identified is more suspicious to an assessor than one that surfaces real problems and shows a remediation path.
Does a real incident count as a test of our IR capability?
Yes. A documented post-incident review of a real incident serves as evidence of IR capability testing and is typically more compelling to assessors than a fabricated tabletop scenario. The review must be documented with the same level of detail: what happened, who responded, what procedures were executed, what gaps were identified, and what was corrected.