- What they do
- Compliance consulting
- Who they help
- Its website offers consulting for HIPAA, CMMC, NIST 800-171, PCI DSS, GLBA / FTC Safeguards and more.
- Standards
- Pricing
- Not published
Incident Response Plan
Get the free fill-in template →
An incident response plan is the written playbook for what your organization does when something goes wrong with its systems or data: who is in charge, how a problem is confirmed and contained, who gets told and by when, how systems come back, and what is written down afterwards. Several US rules require one in writing.
The FTC Safeguards Rule lists seven areas the plan must cover, New York DFS lists nine, PCI DSS lists its own set, HIPAA requires security incident procedures, and the SEC's amended Regulation S-P requires a written incident response program for brokers, advisers, funds and transfer agents.
An incident and a breach are not the same thing. An incident (HIPAA says "security incident", the FTC says "security event", NY DFS says "cybersecurity event") is any attempted or actual unauthorized access, use or disruption: a phishing email that someone clicked, malware on a laptop, a server outage caused by an attack. Most incidents never become breaches.
A breach is the narrower case where protected information was actually acquired, accessed or disclosed without permission in a way the law defines, and that is what starts most notification clocks. Your plan has to handle every incident and include a step that decides, and records, whether the incident is a reportable breach under each rule that applies to you.
That step is why one plan has to serve several clocks. A single ransomware attack at a mortgage broker with New York customers and a defense contract could require notice to NY DFS within 72 hours of determining a cybersecurity incident occurred, a report to DoD within 72 hours of discovery, notice to the FTC within 30 days if 500 or more consumers' unencrypted information was acquired, and notices to individuals under each state's breach law (30 days in Colorado and Washington, 45 in Arizona, 60 in Texas, "without unreasonable delay" in many others).
A health care company has 60 days under HIPAA. The clocks start at different moments (discovery, determination, awareness), so the plan should name who records each of those moments and keep a table of every deadline that applies.
Notification deadlines at a glance.
One incident can start several clocks, each at a different moment. These are the notice deadlines for the rules on this page. The conditions for each are in the ledger below.
| Rule | Who must notify | Deadline | Clock starts |
|---|---|---|---|
| NY DFS Cybersecurity Regulation 23 NYCRR 500.17(a), (c) | Entities licensed by NY DFS | 72 hours; 24 hours after any extortion payment | After determining a cybersecurity incident occurred |
| DFARS cyber incident reporting DFARS 252.204-7012(c) | Defense contractors with DFARS 252.204-7012 in the contract | 72 hours | After discovery of the cyber incident |
| GDPR GDPR Art. 33 | Controllers of personal data covered by GDPR | 72 hours where feasible | On becoming aware of the breach |
| FTC Safeguards Rule 16 CFR 314.4(j) | Financial institutions under FTC jurisdiction | 30 days, when 500 or more consumers are involved | After discovery of unauthorized acquisition of unencrypted customer information |
| SEC Regulation S-P 17 CFR 248.30(a)(4) | SEC-registered brokers, dealers, funding portals, investment companies, advisers and transfer agents | 30 days, to affected individuals | After becoming aware of the unauthorized access or use |
| State breach notification laws C.R.S. 6-1-716; RCW 19.255.010; A.R.S. 18-552; Tex. Bus. & Com. Code 521.053 | Anyone holding personal information about residents of the state | 30 days in Colorado and Washington, 45 in Arizona, 60 in Texas; other states differ | Set by each state |
| HIPAA Breach Notification Rule 45 CFR 164.404 to 164.410 | HIPAA covered entities and business associates | 60 calendar days | After discovery of the breach |
Who requires it, and what each one says.
| Source | Applies when | What it requires | Status |
|---|---|---|---|
| FTC Safeguards Rule, written incident response plan 16 CFR 314.4(h) | Non-bank financial institutions under FTC jurisdiction that maintain customer information on 5,000 or more consumers (314.6) | A written incident response plan designed to promptly respond to, and recover from, any security event materially affecting the confidentiality, integrity or availability of customer information. It must address goals; internal processes; roles, responsibilities and decision-making authority; internal and external communications; remediation of identified weaknesses; documentation and reporting of security events; and evaluation and revision of the plan after an event. Legally required. | Mandatory |
| FTC Safeguards Rule, notice to the FTC 16 CFR 314.4(j); effective May 13, 2024 (314.5) | A notification event (unauthorized acquisition of unencrypted customer information) involving at least 500 consumers. Applies regardless of the 5,000-consumer exception | Notify the FTC electronically on the form on ftc.gov as soon as possible and no later than 30 days after discovery. The notice states the institution's name and contact, the types of information involved, the date range if known, the number of consumers affected, a general description, and whether law enforcement asked for a delay. Discovery is the first day the event is known to any employee, officer or agent other than the person committing the breach. Legally required. | Mandatory |
| NY DFS Cybersecurity Regulation, incident response and business continuity 23 NYCRR 500.16(a)(1), (b), (c), (d) (Second Amendment, effective November 1, 2023; new 500.16 requirements apply from November 1, 2024 under 500.22(d)(2)) | Covered entities licensed by NY DFS, except those exempt under 500.19(a), (c) or (d) | Written incident response plans covering, for different types of cybersecurity events including ransomware: goals; internal processes; roles, responsibilities and decision-making authority; internal and external communications; remediation of weaknesses; documentation and reporting; recovery from backups; a root cause analysis describing how and why the event occurred, its business impact and what will prevent recurrence; and updating the plan. Current copies must be accessible during an event to employees who carry out the plan, those employees must be trained, and the plan must be tested at least annually with all staff and management critical to the response. A separate business continuity and disaster recovery plan is required by 500.16(a)(2). Legally required. | Mandatory |
| NY DFS Cybersecurity Regulation, notices to the superintendent 23 NYCRR 500.17(a) and (c); definition of cybersecurity incident at 500.1(g) | A cybersecurity incident at the covered entity, its affiliates or a third-party service provider (one that must be reported to another government body, is reasonably likely to materially harm normal operations, or deploys ransomware in a material part of its systems); or any extortion payment | Notify the superintendent electronically as promptly as possible and no later than 72 hours after determining a cybersecurity incident occurred, then provide requested information and updates. For an extortion payment, notice within 24 hours of payment and, within 30 days, a written explanation of why payment was necessary, alternatives considered and sanctions diligence. The limited exemption in 500.19(a) does not remove 500.17. Legally required. | Mandatory |
| PCI DSS v4.0.1, incident response plan PCI DSS v4.0.1 Requirement 12.10.1 (contents) and 12.10.2 (review and test at least once every 12 months); 12.10.3 to 12.10.7 (24/7 availability, training, alert response, plan evolution, unexpected stored card numbers) | Merchants and service providers that store, process or transmit cardholder data, through their acquirer or card brand contracts | An incident response plan ready to activate for suspected or confirmed security incidents, covering roles, responsibilities and communication and contact strategies including notification of payment brands and acquirers; containment and mitigation procedures for different incident types; business recovery and continuity; data backup processes; analysis of legal requirements for reporting compromises; coverage of all critical system components; and reference to or inclusion of the payment brands' incident response procedures. Reviewed, updated and tested at least once every 12 months. Required for a passing ROC or SAQ; contractual, not law. | Attestation |
| HIPAA Security Rule, security incident procedures 45 CFR 164.308(a)(6)(i) and (ii); written documentation under 164.316 | Covered entities and business associates that create, receive, maintain or transmit electronic protected health information | Policies and procedures to address security incidents. The required response and reporting specification says to identify and respond to suspected or known security incidents, mitigate harmful effects to the extent practicable, and document security incidents and their outcomes. A security incident is any attempted or successful unauthorized access, use, disclosure, modification or destruction of information, or interference with system operations (164.304). Legally required. | Mandatory |
| HIPAA Breach Notification Rule 45 CFR 164.400 to 164.414 (definition of breach at 164.402; individuals 164.404; media 164.406; HHS 164.408; business associates 164.410) | A breach of unsecured protected health information | An impermissible use or disclosure is presumed to be a breach unless a documented four-factor risk assessment shows a low probability of compromise. Notify affected individuals without unreasonable delay and no later than 60 calendar days after discovery; notify HHS at the same time for 500 or more individuals, or in an annual log within 60 days after year end for fewer; notify prominent media for more than 500 residents of a state; business associates notify the covered entity within 60 days. Legally required. A related duty the incident plan feeds, not the plan itself. | Mandatory |
| NIST SP 800-171 Rev 2, incident response family (assessed under CMMC Level 2) NIST SP 800-171 Rev 2, requirements 3.6.1, 3.6.2, 3.6.3 | Contractors handling controlled unclassified information under DFARS 252.204-7012, and CMMC Level 2 assessments | Establish an operational incident-handling capability that includes preparation, detection, analysis, containment, recovery and user response activities (3.6.1); track, document and report incidents to designated officials and authorities inside and outside the organization (3.6.2); and test the incident response capability (3.6.3). Legally required where the contract clause applies. Rev 2 names a capability rather than a written plan; how it is met is documented in the system security plan (3.12.4). | Mandatory |
| DFARS cyber incident reporting DFARS 252.204-7012(c) to (g) (MAY 2024) | A cyber incident affecting a covered contractor information system, the covered defense information in it, or operationally critical support | Review for evidence of compromise and report to DoD at dibnet.dod.mil within 72 hours of discovery (the clause's definition of "rapidly report"). Reporting requires a DoD-approved medium assurance certificate. Submit isolated malicious software to the DoD Cyber Crime Center, preserve images of affected systems and relevant monitoring data for at least 90 days after the report, and give DoD access for forensic analysis on request. The Department now styles itself the Department of War; the clause and reporting site still say DoD. The July 2026 suspension of CMMC Phase 2 did not change this clause. Legally required as a contract term. | Mandatory |
| SEC Regulation S-P, incident response program 17 CFR 248.30(a)(3) and (a)(4) (89 FR 47688, June 3, 2024; effective August 2, 2024) | SEC-registered brokers and dealers, funding portals, investment companies, investment advisers and transfer agents. Compliance required since December 3, 2025 for larger entities and June 3, 2026 for smaller entities | Written policies and procedures that include a program reasonably designed to detect, respond to and recover from unauthorized access to or use of customer information: assess the nature and scope of an incident, contain and control it, and notify affected individuals whose sensitive customer information was or is reasonably likely to have been accessed or used, as soon as practicable and no later than 30 days after becoming aware, unless a reasonable investigation shows no likely substantial harm. Service providers must be required to notify the institution within 72 hours of a breach affecting a customer information system they maintain. Legally required. | Mandatory |
| SOC 2, system operations criteria AICPA TSP section 100, 2017 Trust Services Criteria (revised points of focus, 2022), CC7.3, CC7.4, CC7.5 | Service organizations undergoing a SOC 2 examination (security is in scope in every SOC 2) | Evaluate security events to decide whether they are security incidents (CC7.3); respond to identified security incidents by executing a defined incident response program to understand, contain, remediate and communicate them (CC7.4); and identify, develop and carry out activities to recover from them (CC7.5). The auditor asks for the written program and evidence it was followed or exercised. Audit criteria, not law. | Attestation |
| ISO/IEC 27001:2022 Annex A, incident management controls ISO/IEC 27001:2022 Annex A controls 5.24, 5.25, 5.26, 5.27, 5.28 | Organizations certifying an ISMS to ISO 27001 (controls are applied through the Statement of Applicability under clause 6.1.3; excluding them needs a justification) | Plan and prepare for incident management by defining processes, roles and responsibilities (5.24); assess events and decide whether they are incidents (5.25); respond under documented procedures (5.26); learn from incidents (5.27); and collect and preserve evidence (5.28). Certification requirement, not law. | Attestation |
| GDPR personal data breach notification Regulation (EU) 2016/679, Articles 33 and 34 | A personal data breach involving personal data covered by GDPR (EU establishment, or offering goods or services to or monitoring people in the EU) | Notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people; processors notify the controller without undue delay; document every breach, its effects and the remedial action (33(5)); tell affected people without undue delay when the risk to them is high (34). Legally required. GDPR does not name a written incident response plan. | Mandatory |
| State breach notification laws For example C.R.S. 6-1-716 (Colorado, 30 days), RCW 19.255.010 (Washington, 30 days), A.R.S. 18-552 (Arizona, 45 days), Tex. Bus. & Com. Code 521.053 (Texas, 60 days) | A breach of computerized personal information about residents of a state; each state defines personal information and breach differently | Notice to affected residents, and often to the state attorney general above a resident threshold, within each state's deadline. Most state laws do not require a written plan; the deadlines are why the plan keeps a state-by-state notification table. Legally required where triggered. | Mandatory |
| NIST SP 800-61 Rev 3 NIST SP 800-61 Rev 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (April 2025) | Any organization looking for a reference structure | Recommendations that tie incident response to the NIST Cybersecurity Framework 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover). Supersedes Rev 2 (2012) and its four-phase lifecycle. Guidance; not required by any rule on this page. | Guidance |
Required sections
- Goals of the plan (16 CFR 314.4(h)(1); 23 NYCRR 500.16(a)(1)(i)), and its scope: which systems, data and locations it covers (scope is best practice; not required by any rule on this page)
- Definitions that separate an event or incident from a reportable breach, using each applicable rule's own terms (HIPAA 164.304 and 164.402; 23 NYCRR 500.1(g); 16 CFR 314.2) (best practice; no rule requires a definitions section)
- Roles, responsibilities and levels of decision-making authority, including who declares an incident and who decides on notification and on any extortion payment (16 CFR 314.4(h)(3); 23 NYCRR 500.16(a)(1)(iii); PCI DSS 12.10.1)
- Contact list and 24/7 availability of responders (PCI DSS 12.10.3), with current copies of the plan reachable during an event (23 NYCRR 500.16(b))
- Internal processes for detection, analysis, containment, eradication and recovery, with procedures for different incident types such as ransomware (16 CFR 314.4(h)(2); 23 NYCRR 500.16(a)(1)(ii); PCI DSS 12.10.1; NIST SP 800-171 3.6.1; 45 CFR 164.308(a)(6)(ii))
- Response to alerts from security monitoring systems and to unexpected discovery of stored card numbers (PCI DSS 12.10.5 and 12.10.7)
- Breach determination step: who decides, on what facts, and how the decision and any HIPAA four-factor risk assessment are recorded (45 CFR 164.402; 17 CFR 248.30(a)(3)(iii))
- Notification table with every regulator, contract party and individual deadline that applies, and the event that starts each clock (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 laws)
- External and internal communications and information sharing, including payment brands and acquirers (16 CFR 314.4(h)(4); 23 NYCRR 500.16(a)(1)(iv); PCI DSS 12.10.1)
- Recovery from backups and link to the business continuity and disaster recovery plan (23 NYCRR 500.16(a)(1)(vii) and (a)(2); PCI DSS 12.10.1)
- Evidence preservation: system images, logs and monitoring data, kept at least 90 days after a DoD report (DFARS 252.204-7012(e); ISO 27001 A.5.28)
- Remediation of identified weaknesses in systems and controls (16 CFR 314.4(h)(5); 23 NYCRR 500.16(a)(1)(v))
- Documentation and reporting of incidents and response activities (16 CFR 314.4(h)(6); 23 NYCRR 500.16(a)(1)(vi); 45 CFR 164.308(a)(6)(ii); NIST SP 800-171 3.6.2; GDPR Art. 33(5))
- Root cause analysis: how and why the event occurred, business impact, and what will prevent recurrence (23 NYCRR 500.16(a)(1)(viii); ISO 27001 A.5.27)
- Service provider duties, including the 72-hour notice service providers must give SEC-registered firms (17 CFR 248.30(a)(5))
- Training for staff with response roles (23 NYCRR 500.16(c); PCI DSS 12.10.4)
- Testing at least annually and after significant changes, with lessons learned (23 NYCRR 500.16(d); PCI DSS 12.10.2; NIST SP 800-171 3.6.3)
- Evaluation and revision of the plan after each incident (16 CFR 314.4(h)(7); 23 NYCRR 500.16(a)(1)(ix); PCI DSS 12.10.6)
- Version, owner, approval date and change log (best practice; not required by any rule on this page)
What the examiner asks for
Change log.
Where this document is required.
Where this document gets checked.
No one certifies a document like this on its own. It is read during the audits and inspections below, and by the agency behind each rule.
| Where it is looked at | Who looks at it |
|---|---|
| CMMC/NIST 800-171 | Level 1 and Level 2 (self): the organization's own assessment with senior official affirmation. Level 2 (certification): a C3PAO authorized by the Cyber AB, using certified CMMC assessors. Level 3: the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) |
| FTC Safeguards/GLBA | Government enforcement only. The FTC investigates and brings enforcement actions; there is no certification or third-party audit requirement. Institutions may commission independent assessments voluntarily or under a consent order |
| HIPAA | Government enforcement only. OCR investigates complaints and breach reports, conducts compliance reviews and periodic audits, and can impose civil money penalties or resolution agreements; state attorneys general may also sue under HITECH. There is no HIPAA certification recognized by HHS; third-party assessments (including HITRUST) are voluntary |
| ISO 27001 | An accredited certification body (registrar) operating under ISO/IEC 17021-1 and ISO/IEC 27006-1:2024, with an accreditation scope that includes ISO/IEC 27001 |
| NY DFS 23 NYCRR 500 | Government enforcement only. DFS examines covered entities and can impose penalties; there is no certification. Class A companies must obtain independent audits of their cybersecurity program (internal or external auditors free from influence over the program), but DFS does not certify those auditors |
| PCI DSS | A PCI SSC qualified Qualified Security Assessor (QSA) company with certified QSA employees performs the ROC. Certified Internal Security Assessors (ISAs) can support internal assessments where the acquirer permits. Approved Scanning Vendors (ASVs) perform quarterly external vulnerability scans. Small merchants self-assess on an SAQ |
| SOC 2 | A licensed CPA firm (independent certified public accountants) performing the examination under the AICPA attestation standards and issuing the service auditor's report |
Consultants.
Firms that name these standards in their own material.
Listed in random order, reshuffled each time the page loads. Firms that pay for a listing are shown at the top, labeled Sponsored.
- What they do
- Compliance consulting
- Who they help
- Its website offers consulting for ISO 27001, SOC 2, HIPAA, CMMC, PCI DSS and more.
- Standards
- Pricing
- Not published
- What they do
- Compliance consulting
- Who they help
- Its website offers consulting for ISO 27001, SOC 2, HIPAA, GDPR, NIST CSF and more.
- Standards
- Pricing
- Not published
- What they do
- Compliance consulting
- Who they help
- Its website offers consulting for ISO 27001, SOC 2, HIPAA, PCI DSS, CMMC and more.
- Standards
- Pricing
- Not published
- What they do
- Compliance consulting
- Who they help
- Its website offers consulting for ISO 27001, ISO 9001, ISO 14001, ISO 45001.
- Standards
- Pricing
- Not published
- What they do
- Compliance consulting
- Who they help
- Its website offers consulting for HIPAA, PCI DSS, GLBA / FTC Safeguards, SOX.
- Standards
- Pricing
- Not published
- What they do
- Compliance consulting
- Who they help
- Its website offers consulting for ISO 27001, SOC 2, HIPAA, PCI DSS, ISO 9001 and more.
- Standards
- Pricing
- Not published
- What they do
- Compliance consulting
- Who they help
- Its website offers consulting for ISO 27001, SOC 2, HIPAA, PCI DSS, GDPR and more.
- Standards
- Pricing
- Not published
Software.
Tools that hold documents like this one and record who has read them.
Need a hand implementing it?
Find a Consultant for Incident Response Plan Requirements: FTC, HIPAA, NYDFS, PCI, SEC
Tell us what you need done and we will point you to firms that do this work. Your details go to a firm only when you choose it.
From the publisher
Manage This Document in AllyMatter
Route it for approval, keep every version, and record a named acknowledgment from everyone who has to read it.
What people ask.
What is the difference between a security incident and a data breach?
An incident is any attempted or actual unauthorized access, use or disruption, such as a phishing click or malware on a laptop. A breach is the narrower case where protected information was actually acquired, accessed or disclosed in a way a specific law defines. Most incidents are not breaches, but the plan must record why each one was or was not.
Which deadline do I follow if several rules apply?
All of them, each on its own clock. NY DFS and DoD each give 72 hours, the FTC 30 days, the SEC's Regulation S-P 30 days for customer notices, HIPAA 60 days, and state laws range from 30 days to "without unreasonable delay". Build a notification table into the plan and work to the shortest deadline first.
When does the clock start?
It depends on the rule. The FTC counts from discovery, meaning the first day any employee, officer or agent knew; HIPAA counts from the first day the breach was known or, with reasonable diligence, would have been known; NY DFS counts from when you determine a cybersecurity incident occurred; DFARS counts from discovery of the cyber incident; Regulation S-P counts from becoming aware. The plan should say who records each of those moments.
I am a small tax preparer. Do I need a written incident response plan?
Under the FTC Safeguards Rule, not if you hold customer information on fewer than 5,000 consumers (16 CFR 314.6). You still must notify the FTC within 30 days of a notification event involving 500 or more consumers, and state breach laws still apply. A short written plan is how you meet those deadlines in practice.
Is the incident response plan the same as a business continuity plan?
No. The incident plan covers detecting, containing, investigating and reporting; the continuity plan covers keeping the business running and restoring operations. NY DFS requires both as separate plans (500.16(a)(1) and (a)(2)), and PCI DSS requires the incident plan to address business recovery and continuity.
How do I test the plan?
A tabletop exercise, where the response team talks through a realistic scenario such as ransomware, is the most common method and is named in NIST SP 800-171's discussion of 3.6.3. Record who attended, what broke and what you changed. NY DFS and PCI DSS require a test at least once a year.
Does a NIST SP 800-61 template satisfy these rules?
It is a good starting structure, but it is guidance and does not list rule-specific items. Check the result against the FTC's seven areas, NY DFS's nine, PCI DSS 12.10.1 and your notification deadlines before relying on it.
Sources
16 CFR 314.4 Elements of an information security program (eCFR)16 CFR 314.6 Exceptions (eCFR)Federal Register, Standards for Safeguarding Customer Information, notification amendment (Nov 13, 2023)Federal Register, Safeguards Rule effective date delay (Nov 23, 2022)NY DFS, Second Amendment to 23 NYCRR Part 500 (text, November 1, 2023)PCI DSS v4.0.1, PCI Security Standards Council document libraryPCI SSC, Just published: PCI DSS v4.0.1 (June 2024)45 CFR 164.308 Administrative safeguards (eCFR)45 CFR Part 164 Subpart D, Notification in the case of breach (eCFR)NIST SP 800-171 Rev 2, Protecting Controlled Unclassified InformationDFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting (eCFR)17 CFR 248.30 Regulation S-P safeguarding and disposal (eCFR)Federal Register, Regulation S-P amendments (June 3, 2024)SEC, Enhancements to Regulation S-P: Small Entity Compliance GuideAICPA, 2017 Trust Services Criteria with revised points of focus (2022)ISO/IEC 27001:2022 (ISO catalog)Regulation (EU) 2016/679 (GDPR), EUR-LexRCW 19.255.010 Washington breach notificationNIST SP 800-61 Rev 3 (April 2025)