Incident Response Plan Template for Manufacturers to Prevent Downtime

An incident response plan is a written, tested plan for what your company does when a cybersecurity incident happens: who leads, who’s told, what gets contained, what evidence is kept, and who has to be notified and when. For a defense manufacturer there’s a built-in deadline. If covered defense information is involved, you have 72 hours from discovery to report to the Department of Defense. 

Most templates online are generic. This one is built for a small manufacturer: the sections a plan needs, the steps, who must be notified, how to test it, and what changes on a shop floor where shutting down the network can stop production. Treat it as a starting point for your own plan, not a form to fill in. 

What Is an Incident Response Plan? 

An incident response plan, sometimes called a cyber incident response plan or a security incident response plan, is the document your team follows when something goes wrong: suspected ransomware, a compromised account, a lost laptop with controlled data, a vendor breach, or an employee mistake. It describes your response processes in enough detail that someone can follow them under pressure. 

It’s different from an incident response policy. The policy is the short, high-level statement of authority and expectations. The plan holds the procedures. Neither counts until someone with approval authority formally adopts it. In a recent policy review with a client, a plan was still waiting on formal adoption before it counted. 

Time is why it matters. IBM’s 2026 Cost of a Data Breach Report puts the mean time to identify and contain a breach at 247 days, and your DFARS reporting deadline is 72 hours from discovery. The decisions have to be made beforehand. It’s also a compliance requirement: NIST SP 800-171, the standard behind CMMC Level 2, requires an operational incident-handling capability (3.6.1), tracking and reporting of incidents (3.6.2), and testing (3.6.3). 

What Should an Incident Response Plan Template Include? 

Use the table as your outline, or as a worked incident response plan example to adapt, whether you’re a small business or a mid-sized shop. Fill in each row with your own systems, people, and phone numbers. 

Section	What it covers	Example detail
Purpose and scope	The systems, locations, and data covered, including the CUI boundary	A list of covered systems and where CUI lives
Roles and contacts	Who leads, who decides, who reports, who communicates	Incident lead, management decision-maker, technical support, DFARS and ITAR reporters, legal counsel, insurer, MSP, after-hours numbers
Definitions and severity	What counts as an incident versus an event	Report suspected compromise by phone; routine phishing only needs a report if someone interacted with it
Employee reporting	How anyone raises a concern, at any hour	The help desk and the employee’s manager; phone calls after hours
Response procedures	Detection, triage, containment, eradication, recovery	Playbooks by scenario: ransomware, lost device, insider, vendor
Evidence handling	What to preserve and how	Preserve images and logs before wiping devices; keep them at least 90 days after a DFARS report
External reporting	Who must be told, and when	The DFARS 72-hour report, malware submission, ITAR disclosure, customers, insurer
Messaging plan	What’s said internally and externally, and by whom	Employee notices, customer notices, a single spokesperson
Recovery and continuity	Restoring operations and working in the meantime	Validated backups, offline production procedures
Testing and maintenance	Exercises, training, updates	An annual tabletop exercise, updates after any incident or change
Records	Tracking every incident from start to finish	A ticket per incident, plus the exercise evidence package

What Are the Steps of an Incident Response Plan? 

The first step is preparation, and it happens before any incident. Most plans follow a six-step lifecycle: 

1. Prepare. Write the plan, name the roles, set up logging and backups, get the DoD certificate you’ll need to report, and train people.
2. Detect. Notice something’s wrong and decide whether it’s an incident. In the plans we build, this includes employee reporting and triage.
3. Contain. Stop the spread: isolate devices, disable compromised accounts, block malicious connections. Containment often has a business cost, covered below.
4. Eradicate. Remove the cause: malware, unauthorized accounts, the vulnerability that let the attacker in. Rushing to recovery first risks restoring the problem.
5. Recover. Restore from validated backups, confirm systems are clean, and return to normal in a controlled way.
6. Review. Document what happened, what worked, and what didn’t, then update the plan. Preserve evidence first.

A note on frameworks: many templates still cite the four phases from NIST SP 800-61 Revision 2. NIST finalized Revision 3 in April 2025, which supersedes it and reorganizes incident response around Cybersecurity Framework 2.0, so a current NIST incident response plan should reflect that. The six steps above are a common model, often attributed to SANS. Either works if your plan covers the same activities and your people can follow it. 

How to Create an Incident Response Plan 

Here’s the order we use with clients: 

1. Define the scope. Which systems, locations, and data does the plan cover? For a defense manufacturer, start with where CUI lives, since that determines what triggers the DoD clock. 
2. Assign roles, and name backups. See the list below. 
3. Define what an incident is. Set thresholds in writing. In plans we’ve built, suspected compromise is reported by phone right away, while routine phishing only needs a report after someone interacts with it or suspects a compromise. A plan that treats every suspicious email as an incident tends to bury the real ones. 
4. Set up reporting. Employees report to the help desk and their manager, with phone calls after hours. 
5. Write the response procedures. Short playbooks for the scenarios you’re most likely to face. 
6. Build in evidence handling. Preserve images and logs before wiping devices. Wiping first destroys evidence you may be required to keep. 
7. List your notification duties. Covered in the next section. 
8. Plan your messaging. Who tells employees, customers, and the press, and what do they say? 
9. Test it, get it formally adopted, and maintain it. 

Assign these roles by name, each with a backup: an incident lead; a management decision-maker with the authority to approve disruptive steps like isolating the network; a technical lead, whether internal IT or your managed provider; a communications lead; a DFARS reporter who holds the DoD certificate; an ITAR reporter, often the Empowered Official, if you’re registered; HR for insider cases; and legal counsel and your insurer’s contact. In several client plans, one person owns both DFARS and ITAR reporting. That works, but name a backup, because the clocks don’t wait for vacations. 

Who Do You Have to Notify? 

Put every notification obligation in one place: 

• DoD, within 72 hours. DFARS 252.204-7012 requires you to rapidly report a cyber incident affecting covered defense information within 72 hours of discovery, through the DoD’s DIBNet portal. It also requires a review for evidence of compromise, including affected systems, data, and user accounts. Treat that as its own checklist. We cover the clause in our guide to DFARS 252.204-7012. 

• The certificate, first. Filing requires a DoD-approved medium assurance certificate. In our experience it takes a couple of weeks to a month to get, far longer than 72 hours, and several clients are working on it now. 

• Malware and evidence. Submit isolated malware to the DoD Cyber Crime Center, and preserve images and monitoring data for at least 90 days from the report. 

• The prime, if you’re a subcontractor. Pass the DoD-assigned incident report number up as soon as practicable. 

• ITAR, on its own clock. Initial notification immediately after discovery, with full disclosure within 60 days. Your Empowered Official and counsel should own this. See our guide to ITAR vs. EAR. 

• Customers, your insurer, and other laws. Many customer contracts set their own notification terms, and insurance policies have notice requirements. Check both now. State breach notification laws may apply, and GDPR has its own clock if you handle personal data of people in the EU. 

The DFARS clause doesn’t replace any of these other duties. 

How Do You Test an Incident Response Plan? 

An untested plan is a guess. NIST SP 800-171 requirement 3.6.3 requires testing, and its discussion lists checklists, walk-through or tabletop exercises, simulations, and comprehensive exercises as ways to do it. 

A tabletop exercise is the practical start for a small shop: a facilitator walks the team through a realistic scenario. We run them annually, about 90 minutes, and some are open-book, with the plan sent beforehand. Keep an evidence package of the scenario, participants, decisions, and follow-ups. A documented tabletop can count as your test. In one engagement, a client asked whether an earlier one would satisfy the requirement, and the answer was that it might, subject to a documentation review. Our guide to running a tabletop exercise covers how. 

Testing and tracking are common gaps. In several recent assessments, incident-response testing was missing, and in one, incident tracking covered only a single tool’s alerts. Track every incident, including small ones, in a ticket or log. Requirement 3.6.2 expects it. 

Containment in a Manufacturing Environment 

Containment is where manufacturing plans differ from generic templates. In an office, isolating a compromised network is an inconvenience. On a production floor, it can stop the line. 

In a recent tabletop exercise, isolating the internet connection was identified as an important containment step and a disruptive one: manufacturing could continue offline temporarily, but administrative and logistics work would be affected. Another exercise found that losing internet access would make most of a company’s operations unavailable. These were scenarios, not real incidents, but your plan should answer the same questions in advance: 

• Who can authorize isolating the network or stopping production? Name that person before an incident. 

• What can run offline, and for how long? 

• What’s the order of recovery? One scenario involved a hardware vulnerability across most workstations, with replacement estimates stretching from three months to six. The team put sensitive systems first. 

For ransomware or malware, the logic is the same: contain, preserve evidence, eradicate, then recover from validated backups. Name any outside provider, such as your managed detection and response partner, and how to reach them after hours. 

Cover supply chain incidents too, like a compromised vendor account or a supplier breach. Your plan should say who to call at the vendor, what your contracts require them to tell you, and how you’d cut off their access. We cover the broader risk in our guide to supply chain cybersecurity. 

If you’re not sure your plan names who files the DoD report, whether they hold the certificate, or who can authorize taking the network down, start there. Our team works with manufacturers in the DoD supply chain on exactly this, and our DFARS compliance work includes building a plan that matches how your shop actually runs. 

Schedule a free consultation with our team to talk through your incident response plan and your reporting readiness. 

FAQs

What is the first step in an incident response plan? 

Preparation: writing the plan, naming roles and backups, setting up logging and backups, obtaining the DoD certificate if you handle covered defense information, and training people. 

Should my plan follow NIST or SANS? 

Either can work. NIST finalized SP 800-61 Revision 3 in April 2025, which supersedes the four-phase Revision 2 many templates still cite. A six-step model commonly attributed to SANS (preparation, identification, containment, eradication, recovery, lessons learned) is popular in practice. Pick one, cover the same activities, and make sure your team can follow it. 

Is an incident response plan required for CMMC? 

CMMC Level 2 includes three incident response requirements from NIST SP 800-171: establish an operational incident-handling capability (3.6.1), track, document, and report incidents (3.6.2), and test it (3.6.3). Separately, DFARS 252.204-7012 requires the 72-hour DoD report whenever covered defense information is involved, whether or not you’ve been certified. 

Can a tabletop exercise count as testing my plan? 

Yes, if it’s documented. NIST’s discussion of requirement 3.6.3 lists tabletop exercises among the accepted ways to test. Keep the scenario, participants, decisions, and follow-up items as evidence.