An incident response plan is a written, step-by-step playbook covering how your business detects, contains, and recovers from a security incident — and who is responsible for each step. It's rehearsed ahead of time so the people involved aren't learning their roles during an actual crisis.

Manufacturers need one for the same reason any business does — faster containment means less damage — plus an added layer: DoD subcontractors are contractually required to have this capability, not just encouraged to have it.

Yes. CMMC's Incident Response domain — built on NIST SP 800-171 practices IR.L2-3.6.1 through 3.6.3 — requires an operational incident-handling capability that covers preparation, detection, analysis, containment, and recovery, along with tracking, documenting, and reporting incidents to appropriate officials.

In plain terms: you need a plan, you need to have actually used or tested it, and you need records showing you did.

DFARS 252.204-7012 defines a reportable cyber incident broadly: any incident that actually or potentially affects a covered contractor information system or the Controlled Unclassified Information residing on it — including compromise, unauthorized access, and events that adversely affect your ability to perform work involving CUI.

Example: a compromised employee laptop that had access to a shared drive holding CUI-related drawings is reportable, even if the attacker never actually opened those specific files.

A risk assessment finds and documents your gaps before anything happens. A penetration test proves whether those gaps are exploitable. Incident response planning is what happens after something does happen — the playbook for detection, containment, recovery, and reporting once an incident is already underway.

All three work together: the assessment and pen test reduce how often you need the incident response plan, and the plan limits the damage on the day you actually need it.

A generic incident response plan often stops at "notify IT and change passwords" — fine for a phishing email, not enough for a halted CNC line or a compromised MES system. A manufacturing-aware plan includes separate playbooks for production-impacting incidents: who can authorize stopping a line, how to isolate affected OT equipment without damaging in-progress work, and how to communicate with customers about delivery delays.

It should also spell out who's authorized to make production-halt decisions — usually not the same person who decides to take a server offline.

Broadly, five phases: detection and analysis (confirming something real is happening), containment (isolating affected systems to stop it spreading), eradication (removing the cause), recovery (restoring systems from clean backups and resuming operations), and a post-incident review (documenting what happened and what changes as a result).

For DoD-related incidents, evidence preservation and the 72-hour reporting clock run in parallel with all of the above — not after it.

DFARS 252.204-7012 requires reporting a cyber incident within 72 hours of discovery, filed through the DoD's DIBNet portal, along with a medium-assurance certificate obtained in advance — not something to figure out for the first time during an active incident.

You're also required to preserve affected systems and images for at least 90 days in case the DoD requests forensic review, which is why containment steps in a good plan are written to avoid destroying evidence.

Initial plan development is typically a fixed-fee project scoped around your systems, sites, and OT footprint. Ongoing cost is usually modest — annual tabletop exercises and plan updates — unless the plan is bundled into a broader managed security or incident response retainer.

Example: for AllTech's typical client — 40 to 75 endpoints, one primary site — building the plan is a modest fixed-fee engagement, far less than the cost of even a single day of unplanned production downtime.

Response gets improvised in real time — figuring out who to call, what to shut down, and what to preserve, all while the incident is still unfolding. That almost always means longer downtime, more data loss, and a higher chance of missing the 72-hour DFARS reporting window or destroying evidence during a rushed cleanup.

It also puts your CMMC compliance status at risk — the Incident Response domain expects a documented, exercised capability, not one built from scratch mid-crisis.

Run a tabletop exercise at least annually — walking through a simulated incident with the actual people who'd respond — and update the plan any time your systems, vendors, or key contacts change. Treat it the same way you'd treat a fire drill: useless if nobody's practiced it, and quickly out of date if it isn't revisited.

Look for a partner who's handled real manufacturing incidents, not just written generic templates — someone who understands the difference between isolating an office laptop and safely isolating equipment tied into an active production line.

Also confirm they can actually be reached during an incident, not just during business hours when the plan was written — a plan is only as good as the people available to execute it.

1. Separate, rehearsed playbooks for office IT incidents and production-impacting incidents.

2. Built around DFARS 252.204-7012's 72-hour reporting clock and evidence-preservation rules.

3. Clear, pre-assigned decision-makers for production-halt calls.

4. Annual tabletop exercises, not a document that sits untouched until it's needed.

5. Real availability during an incident — the same team you can reach to help respond, not just to write the plan.