Incident response plan template.

NOTICE: DELETE THIS WHOLE NOTICE BEFORE YOU USE THIS PLAN

This template is general information, not legal advice. Using it does not make Policy & Compliance or AllyMatter Inc your lawyer, and it does not create a lawyer-client relationship.

Laws, thresholds and deadlines change and differ by state and industry. This plan will not fit your organization until you adapt it. Remove what does not apply, fill in every blank, and have a lawyer check the notification table before you rely on it.

Policy & Compliance and AllyMatter Inc give no warranty and accept no liability for how you use this template or for any incident, penalty or loss that follows.

You use it at your own risk. Delete this notice, and every [square bracket], only after you have read it and adapted the plan. Do not adopt this plan with this notice still in it.

Incident Response Plan

[Company legal name]  |  Version [1.0]  |  Approved by [Name, title] on [date]  |  Next review [date, at most 12 months out]

1. Purpose, scope and owner

This plan sets out what [Company] does when an event threatens the confidentiality, integrity or availability of its systems or data. Its goals are to find problems quickly, limit the damage, restore normal operations, meet every legal and contractual notice deadline, and learn from each event.

It covers [all company systems, devices, cloud services, locations and people, including contractors and service providers who handle company data]. It does not cover [exclusions, if any]. The plan owner is [role]. The owner keeps this plan current and makes sure responders can reach a copy during an event, including when company systems are down.

Rules this part covers: 16 CFR 314.4(h)(1); 23 NYCRR 500.16(a)(1)(i) and (b)

2. Definitions

• Event: anything observed that might affect security, such as an alert, an odd login or a lost laptop.
• Incident: an event that is an attempted or actual unauthorized access, use, disclosure or disruption of systems or data. Some rules use their own words for this: "security incident" (HIPAA), "security event" (FTC Safeguards Rule), "cybersecurity event" (NY DFS).
• Breach: the narrower case where protected information was actually acquired, accessed or disclosed without permission in a way a specific law defines. A breach under one rule may not be a breach under another. Most incidents are not breaches.

Rules this part covers: 45 CFR 164.304 and 164.402; 23 NYCRR 500.1(g); 16 CFR 314.2

3. Roles, responsibilities and authority

Each role below has a named person and a backup. Only the incident commander declares an incident. Only the notification decision-maker decides whether a notice is sent. Only the executive sponsor approves an extortion payment, after counsel has checked sanctions and notice duties.

Rules this part covers: 16 CFR 314.4(h)(3); 23 NYCRR 500.16(a)(1)(iii); PCI DSS 12.10.1 and 12.10.3

4. Severity levels

Set a level when an incident is declared and revise it as facts change.

5. Response procedure

5.1 Detect and report. Anyone who sees a possible incident reports it to [email or phone number] at once, without trying to fix it. The person who takes the report opens an incident record (Appendix A) and tells the incident commander.

5.2 Analyze.

1. Confirm whether the event is an incident, and record the date and time it was first detected.
2. Find out what systems, data and people are affected, and whether protected information is involved.
3. Set the severity level and decide who needs to join the response.
4. Write down the moments that start notice clocks: discovery, determination and awareness (Appendix B).

5.3 Contain. Isolate affected devices and accounts, block malicious addresses, reset exposed credentials and, where needed, take affected systems offline. Choose the action that stops the spread while keeping evidence. Record each step with the time it was taken.

5.4 Eradicate. Remove malware, close the way in, patch the weakness and check that the attacker has no other access before systems return to service.

5.5 Recover. Restore systems from known-good backups, check them before reconnecting, and watch them closely for [30] days. Follow the [Business Continuity and Disaster Recovery Plan] for restoring operations.

5.6 Preserve evidence. Keep disk and memory images of affected systems, logs and monitoring data for at least [90 days, or longer where a rule or counsel requires]. Where a report to the Department of Defense is made, keep the images and monitoring data for at least 90 days after the report.

5.7 Special cases.

• Ransomware: [steps for isolating systems, confirming backups are clean, and the extortion payment decision in section 3].
• Alerts from security monitoring tools: [who watches them, and how fast they are acted on].
• Unexpected stored payment card numbers: [secure delete or move, and report to the incident commander].
• Incident at a service provider that holds our data: [who we call, and how we get their findings].

Rules this part covers: 16 CFR 314.4(h)(2); 23 NYCRR 500.16(a)(1)(ii) and (a)(2); PCI DSS 12.10.1, 12.10.5 and 12.10.7; NIST SP 800-171 3.6.1; 45 CFR 164.308(a)(6)(ii); DFARS 252.204-7012(e)

6. Decide whether it is a reportable breach

For every incident that may involve protected information, the notification decision-maker decides, for each rule in section 7, whether the incident is a reportable breach, and writes down the decision and the facts it rests on.

Where HIPAA applies, an impermissible use or disclosure of protected health information is presumed to be a breach unless a documented risk assessment shows a low probability of compromise. The assessment weighs four factors:

1. The nature and extent of the information involved, including the types of identifiers and the likelihood it can be tied to a person.
2. The unauthorized person who used the information or received it.
3. Whether the information was actually acquired or viewed.
4. The extent to which the risk has been reduced.

Rules this part covers: 45 CFR 164.402; 17 CFR 248.30(a)(3)

7. Notification table

Fill in a row for every rule and contract that applies to [Company]. Delete rows that do not. Have counsel check this table at least once a year, because deadlines and thresholds change and state laws differ. The deadlines below are the ones this site lists for the rules named; confirm them against the current text before relying on them.

Rules this part covers: 16 CFR 314.4(j); 23 NYCRR 500.17; DFARS 252.204-7012(c); 45 CFR 164.404 to 164.410; 17 CFR 248.30(a)(4); GDPR Art. 33 and 34; state breach laws

8. Communications and information sharing

Only the communications lead, with the notification decision-maker, speaks for [Company] outside the response team. Staff who are asked about an incident say: "[Holding statement]" and refer the request to [role].

• Internal: [how and when staff are told, and what they are told not to do].
• Customers and partners: [who drafts, who approves, which channel].
• Regulators: [who files each notice, using which form or portal].
• Information sharing: [payment brands and acquirer, industry sharing groups, law enforcement contact].

Rules this part covers: 16 CFR 314.4(h)(4); 23 NYCRR 500.16(a)(1)(iv); PCI DSS 12.10.1

9. Service providers

Contracts with service providers that hold [Company] data require them to tell [Company] about an incident [within 72 hours, or sooner where a rule requires], and to give the facts [Company] needs to meet its own deadlines. Where [Company] is an SEC-registered firm, a service provider must notify it within 72 hours of a breach affecting a customer information system the provider maintains.

Rules this part covers: 17 CFR 248.30(a)(5)

10. Remediation and root cause

Within [30] days of closing an incident the incident commander writes a short report: how and why it happened, the business impact, and what will prevent a repeat. Each weakness found gets an owner and a due date, tracked to completion.

Rules this part covers: 16 CFR 314.4(h)(5); 23 NYCRR 500.16(a)(1)(v) and (viii); ISO/IEC 27001:2022 A.5.27

11. Documentation and reporting

Every incident has a record (Appendix A) that is kept for [at least 6 years, or the longest period any rule requires]. The incident commander reports incidents and response activity to [the board or senior management] at least [annually, and after any high or critical incident].

Rules this part covers: 16 CFR 314.4(h)(6) and (i); 23 NYCRR 500.16(a)(1)(vi); 45 CFR 164.308(a)(6)(ii) and 164.316(b); NIST SP 800-171 3.6.2; GDPR Art. 33(5)

12. Training and testing

Everyone with a role in section 3 is trained on it when they start and [every year]. The plan is tested at least once a year with all critical staff and management, using [a tabletop exercise built on a realistic scenario such as ransomware], and after any significant change to systems or the business. The test includes restoring from backups. Each test is written up with what went well, what did not, and the fixes agreed.

Rules this part covers: 23 NYCRR 500.16(c) and (d); PCI DSS 12.10.2 and 12.10.4; NIST SP 800-171 3.6.3

13. Review and revision

The plan owner reviews this plan at least every 12 months and after every incident, using what the response and the test taught. Changes are approved by [role] and logged below.

Rules this part covers: 16 CFR 314.4(h)(7); 23 NYCRR 500.16(a)(1)(ix); PCI DSS 12.10.6

Appendix A. Incident record

Appendix B. Notice clock log

Fill in the moment each clock starts. The moments differ by rule, so record all of them.