StealthTech
Nearly every organization we talk to already has an incident response policy. It’s usually a well-formatted document, often built from a template, sitting in a folder alongside the rest of the compliance library. Almost none of those organizations have actually run it. That gap, between having a plan and having tested a plan, is exactly what CMMC’s Incident Response domain is built to catch, and it’s one of the areas where a C3PAO assessor can tell within minutes of an interview whether the documentation reflects a real capability or an artifact assembled for the assessment.
This is worth a dedicated look because the Incident Response domain, despite being only three requirements out of 110, is disproportionately revealing. A contractor can have a forty-page incident response plan, cite it confidently in an interview, and still fail the domain because nobody in the room can describe what actually happens in the first hour of a real incident. This piece breaks down what IR.L2 requires control by control, why testing is treated as a separate and non-negotiable requirement, and what a program that survives both a real incident and an assessment actually looks like.
It’s also worth understanding why this domain gets disproportionate assessor attention relative to its size. Access control and identification and authentication together account for a third of the entire framework, and it would be reasonable to assume incident response, at just three requirements, gets a lighter pass. In practice, the opposite tends to happen. Because IR.L2-3.6.3 specifically demands demonstrated testing rather than described intent, this domain is one of the few places in the entire assessment where the gap between documented compliance and actual operational readiness becomes visible in a single conversation, which is exactly why experienced assessors probe it carefully regardless of how polished the surrounding documentation looks.
Three Controls, Not One Policy Document
The Incident Response domain in NIST SP 800-171, and correspondingly in CMMC Level 2, breaks into exactly three requirements. IR.L2-3.6.1 requires an operational incident-handling capability covering preparation, detection, analysis, containment, recovery, and user response activities. IR.L2-3.6.2 requires tracking, documenting, and reporting incidents to designated officials and authorities, both internal and external. IR.L2-3.6.3 requires testing the incident response capability itself, separate from having built one.
Treating these as three checkboxes satisfied by a single policy document is the most common mistake in this domain, and it’s an understandable one, since a well-written IR policy can genuinely appear to address all three at a glance. It describes handling procedures, it mentions reporting obligations, and it might even include a line about periodic testing. The problem is that a document describing a capability is not evidence the capability exists, and IR.L2-3.6.3 exists specifically because the DoD has learned that distinction matters enormously in practice.
IR.L2-3.6.1: The Difference Between a Policy and a Capability
An operational incident-handling capability means the organization can actually execute preparation, detection, analysis, containment, recovery, and user response, not that it has written down what those steps would theoretically involve. Preparation means the tools, contacts, and access needed during an incident exist and are current, not aspirational. Detection and analysis depend on logging and monitoring infrastructure that’s actually collecting and reviewing the right data, not a SIEM license that was purchased and never fully configured. Containment and recovery require pre-established authority: does the on-call technician actually have permission to isolate a compromised system at 2 a.m. without waiting for an executive to wake up and approve it, or does the plan assume an approval chain that doesn’t function outside business hours.
This is where role clarity matters more than most organizations initially plan for. A policy that assigns incident response duties to “IT” without naming specific roles, backup coverage, and escalation paths reads as incomplete the moment an assessor asks who specifically does what during an active incident, and whether that person is reachable if they’re on vacation.
IR.L2-3.6.2: Tracking, Reporting, and the 72-Hour Clock
Reporting obligations under IR.L2-3.6.2 extend beyond internal tracking into a specific, legally binding external deadline. Under DFARS 252.204-7012, a contractor that discovers a cyber incident affecting covered defense information must rapidly report it, defined explicitly as within 72 hours of discovery, to the DoD through the DIBNet portal. That clock starts at discovery, not at confirmation, not at the end of a convenient business day, and not once legal counsel has finished reviewing the language of the report.
Internal tracking has to support that external deadline, which means the organization needs a clear, documented definition of what counts as “discovery” in operational terms, an alert promoted to a confirmed incident, for example, rather than leaving that determination to ad hoc judgment in the middle of an active event. DFARS 7012 also requires preserving system images and relevant monitoring data for at least 90 days following a report, and organizations without a defined evidence preservation process discover, usually during their first real incident, that critical logs have already rotated out of retention by the time anyone thinks to ask for them.
The Medium Assurance Certificate Nobody Gets Until It’s Too Late
One of the more specific and consistently overlooked requirements buried in DFARS 252.204-7012 is that reporting a cyber incident through DIBNet requires a DoD-approved medium assurance certificate, obtained in advance through the DoD’s External Certification Authority program. This isn’t something that can be requested and issued in the middle of an active incident. It takes time to obtain, and an organization that waits until it needs to file a report to discover this requirement exists has already lost meaningful hours off a 72-hour clock before the reporting process has even started.
This single detail is a useful test of whether an IR program has actually been operationalized versus documented. If nobody in the organization can produce the certificate, or even confirm who holds it and where it’s stored, that’s a concrete, checkable gap, not a matter of interpretation. It’s also exactly the kind of detail a tabletop exercise surfaces immediately and a policy review never catches.
IR.L2-3.6.3: Why Testing Is Its Own Separate Requirement
The DoD didn’t need to make testing its own numbered requirement if a documented plan were sufficient evidence of capability. It did so because the two things are demonstrably different in practice, and acceptable testing methods span a range from structured checklists and walk-throughs to full tabletop exercises and live simulations, with the expectation that testing happens periodically and after any significant change to systems or environment, not as a one-time exercise conducted before a certification and never repeated.
A tabletop exercise, the most common and cost-effective testing method for small and mid-sized contractors, walks a realistic incident scenario through the organization’s actual response process with the people who would actually be involved, without touching live systems. The goal isn’t a performance for an assessor. It’s finding out, in a low-stakes setting, exactly where the plan breaks down before it breaks down during a real event.
Why the First Tabletop Almost Always Fails
It’s worth setting expectations honestly here: the first tabletop exercise an organization runs almost never goes smoothly, and that’s the point, not a failure. Recurring failure patterns show up across nearly every first attempt: the medium assurance certificate can’t be located or has expired in the majority of first exercises, legal review of the incident report consumes far more time than anyone budgeted because counsel has never actually reviewed a DIBNet submission before, the timestamp for when the incident was “discovered” turns out to be genuinely ambiguous once the group tries to pin it down, and the internal approval chain required to submit anything externally depends on a signature from someone who turns out to be unreachable during the exercise’s simulated timeframe.
Every one of those failure points is inexpensive to fix once it’s identified in a tabletop and expensive, in every sense, to discover for the first time during an actual incident with a real 72-hour clock running and CUI genuinely at risk. This is the entire argument for testing as a distinct, non-deferrable requirement rather than a formality layered on top of a policy: the plan that looks complete on paper and the plan that survives contact with a simulated deadline are frequently not the same plan.
A realistic tabletop scenario for a defense contractor typically involves a known type of incident, malware detected on an engineering workstation, a phishing-driven credential compromise, or unauthorized access to a file server holding technical drawings, run on a compressed timeline that still forces the group to confront the actual 72-hour deadline rather than treating it as an abstraction.
A well-designed exercise includes at least one deliberate complication: the person who first noticed the issue is unreachable, the certificate needed for reporting can’t immediately be located, or the initial timeline of events turns out to be genuinely unclear once the group tries to reconstruct it. Those complications aren’t there to be unfair. They’re there because real incidents include exactly that kind of friction, and a tabletop that goes too smoothly hasn’t actually tested anything.
What Assessors Actually Ask to See
During interviews, assessors probe specifically for whether the person describing the incident response process owns it operationally or is reciting language from a document they didn’t write and haven’t used. Expect questions aimed at exactly the gaps a tabletop would expose: who is the first point of contact when a suspicious event is noticed, what’s the process for determining whether something rises to a reportable incident, who has authority to isolate a system without waiting for higher approval, and where does the medium assurance certificate live and who can access it.
Beyond interviews, assessors expect documented evidence of actual testing: tabletop exercise records, after-action reports identifying what went wrong and what was fixed as a result, and a testing cadence that shows this happens on a recurring schedule rather than once, years ago, before the last recertification cycle. A System Security Plan that describes an incident response capability but has no corresponding testing evidence attached is describing an intention, not a control that’s been verified to work.
The after-action report deserves particular care, since it’s often the single artifact that does the most work in an assessor’s evaluation of this domain. A strong one includes a timeline of the exercise, what worked, what didn’t, specific remediation items with named owners and deadlines, and evidence that those remediation items were actually closed before the next test cycle rather than carried forward indefinitely. A stack of after-action reports that all identify the same unresolved gap year after year tells an assessor something very different than a program that visibly improves with each cycle.
If You Use a Managed Provider, You’re Still on the Hook
Many small and mid-sized contractors rely on a managed service provider or managed security service provider for some or all of their monitoring, detection, and response capability, and that’s a reasonable and common architecture. What it doesn’t do is transfer accountability. The contractor remains fully responsible for meeting IR.L2 requirements even when an MSSP is doing the technical work, and assessors expect that relationship to be documented explicitly rather than assumed.
A shared responsibility matrix, spelling out exactly which party detects, which party decides whether something is reportable, which party executes containment, and which party owns the DIBNet submission, is the artifact that turns a vague vendor relationship into something an assessor can actually evaluate. Without it, an interview question as simple as “who decides whether this incident meets the DFARS reporting threshold” can produce two different answers from the contractor and the provider, which is precisely the kind of inconsistency that turns a routine interview into a documented finding.
What an Incident Response Plan Should Actually Contain
Beyond the control text itself, an IR plan that holds up operationally covers a specific set of ground: how an event gets escalated from a suspicion to a confirmed incident, who has authority to make containment decisions and under what circumstances they can act without waiting for approval, how internal stakeholders (leadership, legal, HR) get looped in and when, how external notification obligations under DFARS 7012 get triggered and executed, and how evidence gets collected and preserved in a way that supports both the incident investigation and the 90-day retention requirement that follows a report.
Communication procedures deserve more attention than they typically get. A plan needs to specify not just that the DoD gets notified, but who drafts that notification, who reviews it, and how long that internal review is allowed to take before it starts eating into the 72-hour window. It should also address communication with primes and subcontractors when an incident touches shared systems or a joint program, since CMMC’s flow-down obligations mean your incident can become someone else’s reporting problem very quickly.
Building an IR Program That Survives Both a Real Incident and an Assessment
The organizations that handle this domain well treat incident response as an operational capability that happens to also satisfy a compliance requirement, not a compliance requirement that happens to produce a document. That starts with the underlying visibility an incident response process depends on: our broader look at why incident response planning is mission-critical for defense contractors covers the operational case for this investment beyond the compliance angle specifically addressed here. Detection depends on monitoring infrastructure that’s actually watching the right systems, which is where a managed SIEM or SOC service earns its place in a CMMC security stack rather than sitting as an underused line item.
Recovery capability ties directly into backup infrastructure; an incident response plan that assumes clean, tested backups are available is only as good as the backup and disaster recovery program actually behind it. And the testing requirement itself is best treated as a recurring calendar commitment, not a project: schedule a tabletop annually at minimum, and after any significant change to systems, personnel, or the environment, and hold onto the after-action reports as the evidence trail an assessor will specifically look for. A managed IT partner with direct CMMC experience can run that program continuously rather than treating it as a pre-assessment scramble, which is exactly the difference between an IR program that reads well and one that actually works when it matters.
Stealth Technology Group builds and tests incident response programs that hold up under a real event and a C3PAO assessment alike. If your incident response plan hasn’t been tested recently, visit our compliance services page, or contact Stealth Technology Group today at (617) 903-5559 to talk with a specialist.
