Most contractors treat incident response like paperwork. Write a document, file it somewhere, forget it. That works fine until something actually happens at two in the morning and nobody knows who to call. Incident response is one of the areas assessors poke at closely, and it’s usually the weakest part of an otherwise solid program. What follows is what a real plan looks like, how it ties into CMMC compliance, and the small habits that keep it from rotting in a shared drive. None of it is complicated. Most of it just gets skipped.
The Section Nobody Wants to Write
Ask ten contractors about their incident response plan, and maybe two will produce something current. The rest say “yeah, we have one” and then go quiet. I get it. Writing about a breach you haven’t had yet feels like homework for somebody else’s class. But assessors ask for it, and they ask for more than just the document.
Three Practices, Not One
Level 2 aligns with NIST SP 800-171, which has a small family of incident response requirements. There’s the documented capability itself, then tracking and reporting events, then testing. Three things. Sounds manageable until you realize most companies are good at one and skip the other two. The testing part is where people get caught. Nothing in the folder shows the plan was ever exercised, and that tells an assessor plenty about the rest of your program.
Write It Down So a Tired Person Can Follow It
You don’t need forty pages. You need something your newest hire could read at 3 a.m. without calling anybody. Cover the basics. What counts as an incident. Who declares one. Who gets woken up. What happens in the first hour. Who talks to customers, and who doesn’t. Who notifies the government and from what email address, because that last one trips people up more than you’d expect. Keep it in plain sentences. Bullets are fine. Just make sure the version on the shared drive is the current one. I’ve watched three revisions surface during a single audit, and none of them matched.
Pick Names, Not Departments
Every plan I’ve read says IT handles it. Then IT says the boss makes the call. Then the boss assumes legal weighs in first. Meanwhile, the thing is spreading. So write actual names. A lead and a backup, because people take vacations in August. Someone who can kill a server without asking permission. Somebody whose only job is writing down what happened, in order, with timestamps. That role feels pointless until you’re rebuilding a timeline three weeks later and everyone remembers it differently. If you’re small, three or four people covering multiple hats is fine. Just be honest about who does what.
The Reporting Clock Is Shorter Than You Think
Here’s the part that catches contractors off guard. Incidents involving covered defense information generally need to be reported within 72 hours. Certain cyber events can run as short as 8 hours under DoD rules. That is not much time to figure out what happened, decide what to say, and get it approved. So put the notification steps in the plan with contact details attached. Print that list. Keep it somewhere you can reach without the network. Half the companies I’ve worked with would be locked out of their own documentation during a real event, which is a detail worth sitting with for a minute.
Test It, or You’re Guessing
If you never test the plan, you’re guessing. The formatting is nice. The guessing is still there. Once a year at minimum, get the right people in a room and walk through a fake breach. An hour is enough. What surfaces is usually boring and fixable. Nobody has the contracting officer’s current number. Two people think they have authority to shut down production. The customer comms draft is from 2021 and mentions a product you discontinued. You can fix all of that in an afternoon. You cannot fix it at 2 a.m.
Logs Are the Proof
You cannot report what you have not logged. Ensure there is something that logs your logins, network communications, and access to sensitive files. Be sure of how long you store such logs. If you rely on a cloud provider for some of your operations, find out what they log and what they will give to you should you request it, since “the provider handles it” is not an acceptable response to your assessor. They want to see your incident handled from detection to resolution, and all evidence must be provided. You can promise it, but you will receive better marks with a closed ticket.
Make It Convenient to Report Something
The most effective detection mechanism is the individual who notices a strange email and reports it. This will only work if reporting is convenient and people are not punished for wrong reporting. One button. The phone number that is visible. A little appreciation to those who reported the false positive because you want ten false positives rather than a single person remaining silent due to embarrassment. Conduct the awareness campaign quarterly. Track who attended the meeting. This is your evidence, and it is easy to
Want the Framework Side?
MAD Security covers the three levels, who the rules apply to, the phased deadlines, and what preparation actually involves. Useful if you’re new to the space, or if your team keeps asking the same questions and nobody has a straight answer.
What Happened When We Tested Ours
Ours was a document from three years earlier. It named someone who’d left the company, and the contact list had a number for an office that had since moved. We sat down to test it, and the whole thing collapsed inside twenty minutes. No idea who to call on the government side. Nobody had thought about customer messaging. Two people assumed the other one was in charge. MAD Security ran that session. No pitch, no slide deck. Just walked us through the mess and pointed at the gaps. Took an afternoon and did more for us than any template I’d bought. I’ve worked with a handful of firms in this space, and I’d rank them among the best.
About MAD Security
MAD Security works with defense contractors on this framework specifically. Services cover assessments, gap identification, control implementation, documentation, and support getting through the actual assessment. They hold Level 2 certification themselves and a perfect 110 SPRS score, so the advice comes from having done the work rather than studied it. If you’re up against a deadline, worth a conversation. Just expect to be involved. They don’t do hand-offs.
Conclusion
Most contractors don’t fail here because they lack tools. They fail because nobody owns the plan, nothing gets tested, and the document describes a company that stopped existing two years ago. Fix the boring parts. Name an owner. Put real numbers on the contact list. Test once a year. Keep the logs you’d want at 3 a.m. Do that, and the plan turns into evidence instead of decoration. That’s the part people miss about CMMC compliance. It isn’t the binder. It’s whether the binder still matches the building.
FAQs
-
How often should we test the incident response plan?
Once a year at minimum, and again whenever something major changes. New cloud provider, new office, new core system, run a tabletop. It doesn’t need to be dramatic. Get the right people in a room, hand them a fake breach, and watch where they freeze. That finds gaps a document hides for months. Write down what broke, then fix it.
-
Who needs to be on the response team?
Not just IT alone. You want someone who can make a legal call, someone who owns customer messaging, and someone with authority to shut systems down. Small companies usually have three or four people wearing several hats. Write the names down. Include backups for each role. Vague ownership is how responses stall while everyone assumes somebody else is already deciding.
-
What reporting timelines apply?
Contractors handling covered defense information generally must report incidents within 72 hours. Certain cyber events run shorter, sometimes as little as 8 hours under DoD rules. That’s not much time to investigate, write something accurate, and get it approved. Put the notification steps in your plan, name who drafts them, and keep those contacts current. Late reporting counts against you.
-
In what way does it differ from disaster recovery?
Disaster recovery brings systems back online after an incident occurs. Incident response focuses on the actual attack and addresses what has to be called, contained, and preserved for the investigation. They are similar processes, and some confusion is inevitable, but make sure that both are planned and not assigned to the same tired person when incidents happen. It is the perfect recipe for failures.
-
What if we are a smaller organization that does not have a security team?
Then do not make the document overly long and broad. Two pages are always better than forty. Include an owner of the plan, an alternate owner of the plan, whom to contact, the first three steps of containment, and do not include any contact numbers. It is important to be able to act quickly in a smaller business environment and know who will make the decisions.