An incident response plan can look complete and still fail when people have to use it. NIST SP 800-171 Rev. 2 requirement 3.6.3 requires testing the organizational incident response capability; the useful test is one that forces real roles to make decisions with incomplete information, use actual tools and contact paths, and record what broke.
For contractors with DFARS 252.204-7012, the tabletop should also exercise the handoff from security triage to contract reporting and evidence preservation. That clause defines rapid reporting as within 72 hours of discovery of a covered cyber incident and requires preservation and protection of relevant system images and monitoring or packet-capture data for at least 90 days from report submission.
Choose a scenario that touches the real CUI architecture
Pick a scenario that could occur in the current assessed environment. Useful examples include phishing that steals a user session to the CUI enclave, ransomware on an engineering endpoint, a lost laptop containing local CUI, compromise of a cloud administrator, suspicious access through an MSP tool, or a subcontractor notification involving shared CUI. Avoid a generic 'hackers attack the network' story with no connection to actual systems.
Define the starting facts and what the exercise controller knows but participants do not. The scenario should identify affected asset types, data flows, security tools, and external parties realistically enough that participants can use the real contact lists, diagrams, logging systems, and response procedures.
Keep the scenario bounded. One exercise can focus on detection and reporting; another can focus on ransomware recovery. Trying to simulate every possible disaster in a single two-hour meeting can produce shallow discussion instead of testable findings.
Build injects that force decisions, not speeches
Use timed injects such as an EDR alert, unusual cloud login, employee phone call, customer question, missing laptop, corrupted backup, external IP address, or new evidence that CUI may have been accessed. Ask participants what they would do next and require them to identify the tool, person, or procedure they would use.
Include ambiguity. The team may know a CUI workstation contacted a suspicious address but not yet know whether data left the network. This tests whether personnel can preserve evidence, contain risk, escalate, and continue analysis without waiting for perfect certainty.
Inject operational friction: the normal security administrator is unavailable, the MSP cannot immediately reach a server, the VPN is down, or a business leader asks whether production can continue. The purpose is not to trap participants; it is to expose single points of failure and undocumented dependencies.
Test the full 3.6.1 lifecycle
Preparation includes contact lists, tools, access, backups, playbooks, and authority. Detection and analysis include triage, evidence sources, incident classification, and scope determination. Containment includes account disablement, endpoint isolation, network blocking, or service restrictions. Recovery includes rebuilding, credential reset, restoration, validation, and return to operation.
Test user response as well. Employees need a clear way to report suspicious events and preserve information. If a user reports phishing by deleting the message and rebooting the laptop before security can collect evidence, the technical team starts at a disadvantage. Include at least one user-originated report in the exercise.
Record decisions and timestamps. The exercise observer should note who made each decision, which information was available, what procedure was used, and where the team became uncertain. Those notes become evidence of testing and input to corrective action.
Add the DFARS 7012 reporting decision without assuming every alert is reportable
When DFARS 252.204-7012 applies, the contractor must rapidly report a covered cyber incident within 72 hours of discovery. The exercise should test who evaluates whether the event meets the clause's reporting condition, who has access to the reporting process, what contract and system information is needed, and who can authorize submission.
Do not train the team that every antivirus alert automatically starts a report. The tabletop should distinguish detection from the determination that a covered cyber incident has occurred, while making sure analysis is fast enough that indecision does not consume the reporting window. Contracts and security personnel should know how to find the applicable clauses for the affected work.
Test information gathering under pressure: contract number, affected systems, CUI or covered defense information involved, incident timeline, indicators, mitigation steps, and points of contact. Pre-stage the account and organizational access needed for the DoD reporting mechanism so registration issues do not become the first task during a real incident.
Exercise evidence preservation and the 90-day requirement
DFARS 252.204-7012 requires contractors to preserve and protect images of affected information systems and relevant monitoring or packet-capture data for at least 90 days from submission of the cyber incident report so DoD can request the media or decline interest. A tabletop should ask exactly who creates images, where they are stored, and how integrity and access are protected.
Identify technical obstacles before an incident. Cloud services may not expose disk images in the same way as physical servers; EDR retention may be shorter than the preservation need; packet capture may not exist; a compromised laptop may be needed for business continuity. Define collection methods and escalation paths for each major platform.
Do not destroy evidence during containment. Reimaging a device immediately may restore productivity but erase information needed for analysis or contractual preservation. The response procedure should identify when forensic capture or log preservation occurs before destructive remediation.
Turn the tabletop into evidence and corrective work
Keep an exercise package with objective, scope, scenario, participants and roles, date, injects, decisions, observations, gaps, and action items. Preserve enough detail to show the incident response capability was actually tested, without filling the package with live secrets, passwords, or unnecessary CUI.
Assign every material gap to an owner and due date. Examples include expired reporting credentials, missing MSP contact, insufficient log retention, unclear authority to isolate a production server, untested backup recovery, or a cloud platform with no evidence-preservation procedure. Track closure and update the incident plan, SSP, diagrams, or contracts as needed.
Repeat exercises with different scenarios and after major architecture or personnel changes. The goal is not to stage one annual meeting for an assessor. A mature program uses each exercise to reduce uncertainty in the next real incident and can show the before-and-after improvement.
Score the exercise on decisions and recoverability, not theater
Use a small set of observable measures: time to identify the incident lead, time to find the affected contract and clause, time to isolate an endpoint, ability to preserve required evidence, ability to reach the MSP or cloud provider, ability to locate reporting credentials, and ability to state the business recovery decision. These are operational measures, not arbitrary CMMC pass/fail thresholds.
Capture where participants guessed. A gap such as 'we think the MSP keeps logs for 90 days' should become a verification task, because uncertainty during a tabletop often predicts failure during a real incident.
- Decision made and by whom
- Evidence or tool used
- Elapsed exercise time
- Dependency or uncertainty exposed
- Corrective action and owner
Write an after-action record that changes the next response
The after-action report should distinguish plan defects, access or tool defects, training gaps, contractual knowledge gaps, and external dependency gaps. That makes remediation concrete: update a contact list, extend retention, obtain reporting access, change authority, test restore procedures, or amend the MSP runbook.
Close the loop. Re-test important corrective actions instead of assuming a revised document fixed the problem. If the exercise discovered that no one could image a cloud workload or that the only reporting credential belonged to a former employee, demonstrate the new process after remediation and retain that evidence.
A short working check
- ✓Select a scenario tied to the real CUI architecture
- ✓Use injects that require participants to make operational decisions
- ✓Test preparation, detection, analysis, containment, recovery, and user response
- ✓Record decisions, timestamps, and responsible roles
- ✓Exercise the DFARS 252.204-7012 reportability and 72-hour workflow when applicable
- ✓Test evidence imaging and 90-day preservation responsibilities
- ✓Create corrective actions with owners and due dates
- ✓Update response documents and repeat exercises after meaningful changes
Common questions
Does reading the incident response plan count as testing 3.6.3?
A stronger test exercises the organizational capability: participants respond to a scenario, make decisions, use procedures and contacts, identify gaps, and document corrective actions. Simply reviewing the document does not demonstrate the same operational test.
Does every security alert have to be reported to DoD within 72 hours?
No. DFARS 252.204-7012 applies to covered cyber incidents under contracts containing the clause. The incident process should rapidly analyze events and determine reportability so a real covered incident is reported within the required window.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
