StealthTech
Every defense contractor we onboard hands us a binder. It has a cover page, a revision history, a section on “purpose and scope,” and a flowchart with boxes like “Detect,” “Contain,” “Recover.” It looks complete. It reads well. And in nearly every case, it would not survive contact with an actual incident, let alone a C3PAO assessment day.
That gap between a policy document and an operational plan is where most CMMC Level 2 organizations get exposed — not because they lack effort, but because IR.L2 was written to test capability, not paperwork. Understanding that distinction is the difference between a control that scores MET and one that gets flagged as a deficiency the assessor can’t overlook.
Why Incident Response Gets Treated as an Afterthought
Incident response tends to get built last and reviewed least. Access control, MFA, and encryption all have visible, testable artifacts — a login screen, a policy toggle, a certificate. Incident response, by contrast, only proves itself during an event nobody wants to have. So it gets written once, usually adapted from a template a compliance consultant or an MSP provided, and then filed away until the next assessment cycle forces someone to reopen it.
That approach worked reasonably well under self-attestation. It does not work under CMMC Level 2, where an assessor is instructed to verify that the organization can actually execute the plan, not merely that the plan exists. The controls in the IR domain, drawn from NIST SP 800-171, require operational maturity: established capability, tracking, analysis, containment, recovery, and — critically — user reporting. A document satisfies exactly one of those requirements. The rest demand evidence of practice.
What IR.L2 Actually Requires
IR.L2 is built around a small number of controls, but each one carries more weight than its brief wording suggests. Stripped of assessment-object jargon, the requirement set breaks down into a few operational obligations an organization has to demonstrate, not just describe:
- An established incident-handling capability that covers preparation, detection, analysis, containment, recovery, and user response activities — not just a document describing those phases, but people and processes that execute them.
- Tracking, documentation, and reporting of incidents to appropriate officials and authorities, both internal and external, including the DoD-mandated reporting obligations tied to covered defense information.
- Testing of the organizational incident response capability at a defined frequency, using a method that actually exercises the plan rather than a tabletop read-through of the document.
Notice what’s missing from that list: nowhere does it say “have a policy.” The policy is implied — every organization needs a documented baseline — but the control language is verb-heavy: establish, track, document, report, test. Assessors are trained to look for the artifacts those verbs produce: incident logs, after-action reports, test records, and evidence that the plan was exercised against something resembling a realistic scenario. Our compliance team sees this misread constantly — an organization believes it’s covered because the policy references all six phases, when the actual gap is that nobody has ever run a drill against it.
Detection Is Not the Same as Response
A recurring failure point is conflating detection tooling with incident response capability. An organization deploys an EDR platform, points to the dashboard, and considers IR.L2 handled. Detection is a prerequisite for response, not a substitute for it. The control set assumes that once something is detected, a human process takes over: someone triages the alert, determines scope, decides whether covered defense information was potentially exposed, and initiates the response sequence.
That handoff — from automated detection to human decision-making — is exactly where most organizations have no defined process at all. Who gets paged. What decision authority they have. How quickly a determination gets made about whether this is a false positive, a contained incident, or something that triggers the DoD reporting clock. None of that lives in a SIEM console. It lives in a plan that specific people have rehearsed, which is a different kind of asset than a policy binder sitting in a shared drive. Organizations running zero-trust architectures tend to have better detection fidelity, but even strong segmentation and identity controls don’t answer the “then what” question once an alert fires.
Analysis and Triage Under Pressure
The analysis phase is where most incident response plans reveal that they were written by whoever was assigned the task, not by whoever would actually be on the call during an incident. A workable plan defines, in advance, what information the response team needs to gather within the first hour: what system was affected, what data classification applies, whether CUI was potentially accessible, and whether the incident originated internally or through a third party.
This is also where the distinction between covered defense information and general business data matters enormously, because it determines whether DFARS reporting timelines apply. Organizations that haven’t mapped where CUI lives — which systems, which file shares, which vendor integrations — cannot make that determination quickly during an actual event. They end up guessing, which either triggers unnecessary reporting or, worse, causes a missed report that becomes its own finding. The National Archives CUI registry and marking guidance exist precisely so organizations can make that determination systematically rather than improvising it during a live incident.
We’ve walked into post-incident reviews where the analysis phase took three days, not because the technical investigation was complex, but because nobody on staff knew, offhand, which servers held CUI. That’s not an IR failure in isolation — it’s a symptom of the same CUI protection mapping gap that shows up across half a dozen other controls.
Containment: The Step Most Plans Never Rehearse
Containment is where the theoretical plan meets operational reality, and it’s the phase most organizations have never actually practiced. A well-written plan will say something like “isolate affected systems from the network.” What it won’t specify — because nobody has tested it — is who has the authority to pull a production server offline, what the rollback process looks like if containment breaks a client-facing system, and how the team communicates internally while containment is underway without accidentally notifying the threat actor that they’ve been detected.
Containment decisions made under pressure, by people who’ve never rehearsed them, tend to be either too slow (extended exposure while people debate authority) or too aggressive (unnecessary business disruption that damages trust with leadership in future incidents). Assessors are looking for evidence that containment procedures have been exercised, which is why the testing requirement in IR.L2 isn’t a formality — it’s the mechanism that surfaces exactly these gaps before a real incident does.
Eradication and Recovery — And Proving You Did Both
Eradication and recovery get glossed over in most policy documents with a single sentence: “restore systems from backup and verify integrity.” In practice, this phase requires evidence that the organization actually understands root cause before restoring, because restoring a compromised system without addressing how the attacker got in simply resets the clock on the same incident.
Recovery also intersects directly with an organization’s backup and disaster recovery posture. A recovery plan that assumes backups are clean, current, and quickly restorable only holds up if that assumption has been tested — not asserted. We’ve seen organizations discover, mid-incident, that their backup retention policy meant the “clean” restore point was also compromised, because the intrusion had been present for weeks before detection. That’s not a hypothetical edge case; it’s a common pattern with living-off-the-land techniques that CISA and nation-state threat advisories have documented extensively across multiple sectors.
Documentation matters just as much here as during analysis. Assessors expect to see a record showing what was done, in what order, and how the organization confirmed the threat was actually eradicated rather than just no longer visible.
The Reporting Clock You Cannot Control
Nothing exposes an untested incident response plan faster than the DoD’s cyber incident reporting requirement. Organizations handling covered defense information are subject to a 72-hour reporting window under DFARS 252.204-7012, a clock that starts the moment an incident is discovered — not once the internal investigation concludes, not once leadership has been briefed, and not once someone drafts a comfortable summary.
Seventy-two hours sounds workable until you map it against an untested process: detection, internal escalation, executive notification, determination of CUI involvement, and drafting a report accurate enough to submit to DIBNet, all compressed into three days while the organization is simultaneously trying to contain the actual incident. Every hour spent figuring out who’s responsible for what is an hour taken directly from that window. This is precisely why testing the plan in advance isn’t optional — it’s the only way to know whether your organization can hit that deadline before the deadline is real.
The reporting obligation itself is spelled out clearly enough in the clause, but the operational burden of meeting it under pressure is what catches organizations off guard. Contractors who’ve read the DFARS clause carefully, but never rehearsed the internal choreography required to comply with it, tend to discover the gap at the worst possible moment.
Testing the Plan Before an Assessor Does
The testing requirement inside IR.L2 is where most organizations do the absolute minimum: an annual tabletop exercise where a facilitator reads a scenario aloud and the team discusses, in general terms, what they’d do. That satisfies the letter of “testing” in the loosest possible interpretation, but it rarely produces the kind of evidence an assessor is looking for, and it almost never surfaces the operational gaps described above.
A test that actually validates the plan needs to produce artifacts: a documented scenario, a record of who participated, decisions made, gaps identified, and — critically — a follow-up showing those gaps were remediated. NIST SP 800-171A lays out the assessment objectives an assessor will use to determine whether this control is genuinely met, and “a meeting occurred” isn’t sufficient evidence against those objectives. What’s needed is a paper trail showing the test exercised the plan under conditions close enough to a real incident that the gaps it revealed are credible.
Organizations that treat this testing cycle seriously usually fold it into their broader security operations rhythm rather than treating it as an isolated compliance task, which is one of the reasons a mature cybersecurity program tends to also produce a stronger IR posture almost as a side effect.
Where MSPs Fit Into IR.L2
Most organizations pursuing CMMC don’t run incident response entirely in-house, and that’s appropriate — the volume and specialization required to maintain 24/7 detection and response capability is beyond what a small or mid-sized contractor can staff internally. But this is also where the shared-responsibility confusion tends to concentrate. An MSP can provide detection tooling, monitoring, and even a documented incident response runbook, but the contractor is the one who signs the attestation and sits across from the assessor.
That means the contractor needs visibility into what their provider actually does during an incident, not just a service description in a contract. We’ve written previously about what MSPs serving defense contractors need to know about this exact division of labor, and the short version is that a good managed IT services or co-managed IT arrangement should make the contractor more capable of demonstrating IR.L2, not more dependent on assurances they can’t independently verify. If your provider can’t produce a test record, an incident log format, or a documented escalation path on request, that’s worth resolving well before assessment day.
It’s also worth remembering that incident response doesn’t operate in isolation from the rest of the security stack. Multi-factor authentication reduces the volume of credential-based incidents your response team has to handle, and organizations that have already gone through an SPRS self-assessment often find that IR.L2 gaps surface alongside gaps in related domains, because the same operational maturity that produces a strong incident response capability tends to produce strong scores elsewhere too.
Building an IR Plan That Survives Both an Incident and an Assessor
The organizations that pass this control comfortably share a few habits. They’ve assigned specific names and phone numbers to specific roles in the plan, not job titles that turn over. They’ve run at least one test in the past year that involved something closer to a live-fire scenario than a discussion. They’ve mapped where CUI actually lives so the analysis phase doesn’t start with a scavenger hunt. And they treat the reporting timeline as an operational deadline to be rehearsed, not a clause to be read once and filed.
None of that requires exotic tooling. It requires the organization to decide, in advance, who does what — and to write that down in a way that’s specific enough to be tested and simple enough to be followed by someone under stress at two in the morning. That’s a materially different document than the policy binder most organizations start with, and closing that gap is usually less about technology spend and more about discipline and rehearsal. Contractors evaluating their broader security posture ahead of certification, including engineering and manufacturing firms handling technical data alongside CUI, tend to find IR.L2 is one of the faster gaps to close once the mapping work is done — it just requires treating it as an operational build, not a paperwork exercise.
Conclusion
IR.L2 was never designed to reward well-formatted documentation. It was designed to confirm that when something goes wrong, your organization can detect it, analyze it, contain it, recover from it, and report it within a timeline the DoD controls — not you. Closing the gap between a policy and a plan is one of the more solvable problems in a CMMC roadmap, but only if it’s treated as an operational exercise rather than a document review.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
