Free Incident Response Plan Template and Policy Generator

This document sets the policy and the plan [Company Name] (the "company") follows to prepare for, detect, respond to, and recover from cybersecurity incidents. Its goals are to protect people first, then to limit damage and cost, preserve evidence, restore operations, and meet every legal and contractual notification duty on time.

Scope. It applies to all employees, officers, temporary workers, contractors, and service providers who use or manage company systems or information ("personnel"). It covers every company system and all company information wherever it is stored or processed, including cloud services, email, laptops and phones, personal devices used for work, plant-floor and operational technology, and systems operated for the company by service providers.

Framework. The plan is designed to align with NIST Special Publication 800-61 Revision 3 and the NIST Cybersecurity Framework (CSF) 2.0, and to support the company in meeting its legal, regulatory, insurance, and contractual obligations. It does not replace those obligations. Where a law, regulation, insurance policy, or contract sets a stricter requirement, the stricter requirement applies.

Authority. This policy is approved by the Chief Executive Officer. During an incident, the people named in this plan have the authority to take the actions it describes, including disconnecting systems and suspending accounts, without waiting for further approval.

Security event

Any observable occurrence in a system or network, such as a failed login or a security alert. Most events are harmless.

Security incident

An event that actually or potentially harms the confidentiality, integrity, or availability of company systems or information, or that violates security policy. Suspected incidents are handled as incidents until ruled out.

Data breach

An incident in which personal, regulated, or confidential information is, or is reasonably believed to have been, accessed or acquired without authorization. Whether an incident is a breach under a specific law is decided by legal counsel.

Ransomware

Malicious software that encrypts or steals data and demands payment to restore it or to not publish it. Extortion without encryption is handled the same way.

Business email compromise (BEC)

Fraud in which an attacker takes over or imitates an email account of an executive, employee, customer, or supplier to redirect payments or obtain information.

Containment

Actions that stop an incident from spreading or causing more harm, such as disconnecting a device or disabling an account.

Eradication and recovery

Removing the cause of an incident, then restoring systems and data to normal, verified operation.

Out-of-band communication

A way to communicate that does not depend on possibly compromised company systems, such as phone calls or a separate messaging account.

Discovery

The time an incident is first known, or reasonably should have been known, to anyone at the company. Many legal notification deadlines run from discovery.

Digital forensics. When an incident may involve data theft, extortion, regulated data, or an attacker with broad access, a qualified digital forensics firm investigates alongside the managed IT provider. The firm is selected from the cyber insurer's approved vendor panel and engaged through outside breach counsel, so its costs are more likely to be covered and its work is coordinated with the claim.

Service providers. Contracts with IT and security service providers must state their response times, their authority to act during an incident, their duty to notify the company promptly of incidents affecting company data, and their duty to preserve evidence and cooperate with investigators.

Complete this roster before the plan is approved. Include a 24/7 phone number for each contact, because incidents rarely happen during business hours. The IT Manager verifies every number at least quarterly and after any change in provider or staff.

After-hours reporting line. The company maintains a phone number for reporting incidents that is answered 24 hours a day, 7 days a week. The number is posted where personnel can find it without logging in to company systems, such as on badges, break room notices, and personal phone contacts.

Offline copies. Printed copies of this plan and roster are kept by the Incident Response Lead, the alternate, and the executive decision-maker, and an electronic copy is kept somewhere that does not depend on company systems. Copies are replaced whenever the roster changes.

The Incident Response Lead assigns a severity level as soon as a suspected incident is reported, and changes it as facts emerge. When in doubt, choose the higher level. Any incident that may involve regulated or personal information, payment fraud, or extortion is at least High until ruled out.

Escalation. If a contact does not answer, call the alternate listed in the roster, then the next level up. Do not wait for a call back before escalating a Critical or High incident.

Report immediately. Personnel must report a suspected incident to the IT Manager or to the after-hours reporting line immediately, and no later than 1 hour after noticing it. For anything urgent, call. Do not rely on email, which may be compromised. Report even if you are unsure, and even if you made a mistake. No one will face retaliation for a good-faith report, and a quick report is always treated more favorably than a delayed one.

Report, for example:

• A ransom note, files that will not open or have strange names, or a computer that suddenly runs very slowly.
• Clicking a link or opening an attachment you now think was suspicious, or entering your password on a suspicious page.
• Multi-factor authentication prompts you did not request.
• Any request to change bank or payment details, or an urgent payment request that bypasses normal approvals.
• Emails sent from your account that you did not write, or replies to messages you never sent.
• A lost or stolen laptop, phone, tablet, USB drive, or badge.
• Company or customer information sent to the wrong person or posted where it should not be.
• A call from a customer, supplier, or bank about a message or payment that did not come from the company.

Do not. Do not turn off, restart, or wipe an affected device, delete messages or files, run your own cleanup tools, contact the attacker, or discuss the incident with anyone outside the company or on social media, unless the response team tells you to.

NIST SP 800-61 Revision 3 describes incident response in terms of the six CSF 2.0 Functions. Govern, Identify, and Protect prepare the company and reduce the chance and impact of incidents. Detect, Respond, and Recover are the response itself. Lessons learned from every incident and exercise feed back into all six. The company applies that model through the following phases.

Recovery priorities. Systems are restored in the order that best protects people and the business: safety systems first, then the systems that let the company take orders, produce or deliver, pay employees, and collect payments, then everything else. No system is reconnected until the technical team confirms it is clean and the Incident Response Lead approves.

Closing an incident. The Incident Response Lead closes an incident only after containment and eradication are confirmed, operations are restored, notification decisions are made and documented, and the post-incident review is scheduled.

For any suspected High or Critical incident, work through this checklist in order. Whoever discovers the incident starts it, and the Incident Response Lead directs it from the moment they are reached. Steps may happen in parallel when enough people are available.

1. Make sure people are safe. If an incident affects equipment, building systems, or anything that could hurt someone, bring it to a safe state first.
2. Disconnect affected devices from the network: unplug the network cable and turn off Wi-Fi. Do not power off or restart them, because that destroys evidence held in memory. Power a device down only if it cannot be disconnected and the infection is spreading.
3. Call the Incident Response Lead, or the alternate if the lead does not answer, and the managed IT provider. Open an incident log and record the time of discovery, who reported it, and every action taken from this point on.
4. Move response communications to the backup channel. Assume the attacker can read company email and chat until the technical team says otherwise.
5. Protect backups: confirm they are intact, and disconnect or lock them so the attacker cannot delete or encrypt them.
6. Disable or reset compromised accounts, revoke their active sessions, and check for newly created accounts, mail forwarding rules, and remote access tools.
7. Assign a severity level and, for a Critical incident, brief the executive decision-maker within 1 hour.
8. Call the cyber insurance breach hotline before hiring any outside vendor, agreeing to pay anything, or admitting fault. Many cyber policies require prompt notice and the insurer's consent before costs are incurred.
9. Call outside breach counsel for any incident that may involve personal, regulated, or customer data, payment fraud, or extortion.
10. If money was sent or is about to be sent, have Finance call the bank immediately. Minutes matter for recalling a transfer.
11. Preserve evidence as described in this plan. Do not delete anything, and do not reimage a device until the technical team has captured what it needs.
12. Note the time of discovery for every legal and contract deadline in this plan, and tell the Incident Response Lead which ones may apply.

Preserve before you fix. Evidence may be needed by insurers, law enforcement, regulators, customers, or a court. Before any system is wiped, reimaged, or restored, the technical team captures what is needed, which may include memory images, disk images, system and security logs, email headers and message traces, cloud audit logs, firewall and remote access logs, and screenshots of ransom notes or fraudulent messages.

Chain of custody. Evidence is labeled, stored securely with access limited to the response team, and logged each time it is collected, moved, copied, or handed to someone else, with the date, time, and name of each person.

Incident log. The Incident Response Lead keeps a written log of each incident: the time of discovery, the severity and any changes to it, systems, data, and people affected, every action and decision with its time and owner, contacts with outside parties, notifications made, and costs incurred. Write facts, not guesses, and do not speculate about fault in writing.

Log retention. System, security, and cloud audit logs must be kept long enough to investigate an incident that is discovered late, at least 12 months where the systems allow it.

Record retention. Incident logs, evidence, reports, and notification records are kept for at least 3 years after the incident is closed.

Legal holds. When outside breach counsel issues a legal hold, all related records must be kept until counsel releases the hold, regardless of any other retention period.

Need to know. Incident details are shared only with people who need them to respond. Personnel must not discuss an incident with customers, suppliers, the media, or on social media, and must direct all outside questions to the communications spokesperson.

Employees. The Incident Response Lead and human resources tell employees what they need to know and do, such as which systems to avoid and how to work in the meantime, through channels that are not compromised.

Customers, suppliers, and partners. Notices to customers, suppliers, and partners are approved by the executive decision-maker and outside breach counsel before they are sent. They are factual, avoid speculation about cause or fault, and tell the recipient what to watch for, such as fraudulent payment requests that appear to come from the company.

Media and public. Only the communications spokesperson speaks to the media or posts public statements about an incident, using statements approved by the executive decision-maker and legal counsel.

Law enforcement and CISA. The company reports every ransomware, extortion, and payment fraud incident, and other High or Critical incidents, to the FBI through ic3.gov or the local field office, and to CISA through cisa.gov/report, after informing outside breach counsel. Law enforcement may ask the company to delay notifying affected people, and some laws allow that delay when it is documented.

Many notification deadlines run from discovery, not from the end of the investigation. At the start of every High or Critical incident, the Incident Response Lead and outside breach counsel identify which of the following may apply and track each one to completion. Legal counsel makes the final decision on whether a notice is required and approves its content.

Other obligations. Contracts, cyber insurance policies, industry regulators, and laws outside the United States may impose additional or shorter deadlines. Legal counsel reviews them at the start of each High or Critical incident. This table is a starting point and does not replace legal advice.

Use this playbook when an email account is taken over or imitated, or when a payment may have been sent to a fraudster. Speed decides whether money can be recovered.

1. If money was sent, Finance calls the bank's fraud department immediately, asks it to recall or reverse the transfer, and requests a hold harmless letter or letter of indemnity. Record the name of every bank contact and every reference number.
2. File a complaint at ic3.gov as soon as possible, regardless of the amount, including the transaction details and the receiving bank information. The FBI may be able to help freeze funds.
3. Notify the cyber insurer and outside breach counsel.
4. Reset the compromised account password, require multi-factor authentication, revoke all active sessions, and remove any mail forwarding rules, inbox rules, delegated access, or connected applications the attacker added.
5. Review sign-in logs and mailbox audit logs to find out when the attacker got in, what they read or sent, and whether other accounts are affected.
6. Warn customers, suppliers, and staff who may have received fraudulent messages, by phone or from a clean account, and tell them to verify any payment instructions by calling a known number.
7. Hold all pending payments to any vendor whose banking details changed recently until each change is verified.
8. Because the attacker may have read the mailbox, legal counsel decides whether personal or regulated information in it triggers breach notification.

Prevention. Every new payment instruction, and every change to existing bank or payment details, must be verified by calling the requester at a phone number already on file, never a number in the request itself, before any payment is made. Urgency, secrecy, or pressure from someone claiming to be an executive is a warning sign, not a reason to skip this step.

1. Follow the first-hour checklist. Isolate affected devices from the network, and disconnect or disable remote access and connections to other sites until they are confirmed clean.
2. Protect and check backups immediately. Attackers commonly try to delete or encrypt them before launching ransomware.
3. Photograph the ransom note and preserve it, and do not open links in it or contact the attacker. Only people authorized by the executive decision-maker, working with counsel, may communicate with an attacker.
4. Notify the cyber insurer, outside breach counsel, and the executive decision-maker, and engage a digital forensics firm as described in this plan.
5. Determine whether data was stolen as well as encrypted. Data theft can trigger notification duties even if systems are restored from backup.
6. Rebuild or restore affected systems from known-good backups, reset every password and credential the attacker may have seen, starting with administrator and service accounts, and close the weakness that let the attacker in.
7. Monitor closely for at least 30 days after recovery, because attackers often try to return.

Ransom payments. The U.S. government strongly discourages paying ransoms, payment does not guarantee that data is restored or deleted, and a payment to a sanctioned person or group may violate U.S. sanctions law. [Company Name] considers payment only as a last resort, and only when all of the following are true:

• Restoring from backups or rebuilding has been evaluated and found not workable in the time the business can survive.
• Outside breach counsel has reviewed the payment.
• The cyber insurer has been consulted, and its consent obtained where the policy requires it.
• A sanctions check confirms that the payment does not involve a person or group sanctioned by the U.S. Treasury Office of Foreign Assets Control (OFAC).
• The incident has been reported to law enforcement.
• The Chief Executive Officer has approved the payment in writing.

No employee or service provider may promise, negotiate, or make a payment on the company's behalf without that approval.

1. The user reports the loss to the IT Manager within 1 hour of noticing it, and files a police report if the device was stolen.
2. The technical team remotely locks the device, and wipes it once the Incident Response Lead confirms nothing on it must be preserved.
3. The technical team resets the user's passwords, revokes the device's sessions and certificates, and removes it from company systems.
4. The technical team confirms and records whether the device was encrypted and whether the encryption key or password could also have been exposed.
5. The Incident Response Lead determines what information was on the device or reachable from it, including email, synced files, and saved passwords.
6. Legal counsel decides whether notification is required. Whether data was encrypted often determines whether a lost device is a reportable breach.

Device standard. Company laptops, phones, and tablets must use full-disk encryption, a screen lock, and device management that allows remote lock and wipe. Personal devices used for work must meet the same standard for the company data they hold.

Post-incident review. Within 14 days after a High or Critical incident is closed, the Incident Response Lead holds a blameless review with everyone involved. The review records what happened and when, what worked, what did not, the root cause, the total cost, and specific corrective actions, each with an owner and a due date. Corrective actions are tracked to completion and reported to the Chief Executive Officer.

Exercises. The response team, including the executive decision-maker and key service providers, runs a tabletop exercise at least once a year, using realistic scenarios such as ransomware on a weekend or a fraudulent wire transfer. Backup restoration is tested as part of or alongside these exercises. Each exercise produces written findings and updates to this plan.

Training. All personnel complete security awareness training at onboarding and at least once a year, covering how to recognize phishing, payment fraud, and suspicious activity and how to report it. Members of the response team receive training on their roles in this plan.

Plan maintenance. The IT Manager owns this document and reviews it no later than September 27, 2027, and sooner after any High or Critical incident, exercise finding, change of IT or security provider, change of insurer, new regulated data, or new contract with notice requirements. The contact roster is verified at least quarterly.

Enforcement. Failing to report a known incident, concealing one, destroying evidence, or paying or negotiating with an attacker without approval may result in disciplinary action, up to and including termination of employment or of a contract, consistent with applicable law. Prompt self-reporting of a mistake is taken into account.

Related policies. This plan works together with the [Company Name] information security, backup and recovery, acceptable use, and remote work policies, where adopted. If they conflict, the stricter requirement applies.

I have read the [Company Name] Incident Response Policy and Plan, I understand my role in it, and I know how to reach the plan and the contact roster without relying on company systems. I will report incidents immediately, preserve evidence, and follow this plan during an incident.

Revision history. Record every change to this policy below. Increase the document version and obtain approval again each time the policy is revised.

This document was generated from a starter template provided by Preferred Data Corporation. It is general information only. It is not legal advice and it is not a substitute for advice from a licensed attorney.

Preferred Data Corporation is not a law firm. It makes no representation that this document is complete, current, or suitable for any particular organization, industry, jurisdiction, or regulatory requirement, and it is not responsible or liable for any use of this template or of any policy created from it. You are solely responsible for how you adapt, adopt, and enforce it.

Laws, regulations, insurance requirements, and contracts that apply to your organization may require different or additional terms. Before you adopt, publish, or rely on this policy, and in every case where you have a legal, regulatory, or contractual obligation, have it reviewed by qualified legal counsel.