Data Breach Incident Response Plan

Disclaimer: This sample plan is being supplied as-is, where is, without any warranties, guarantees, or other representations, including fitness for any purpose.

Data Breach Incident Response Plan

Authorized By: [Board, CEO, or other senior official who has reviewed and approved the policy]

Incident Response Team Members

IRT Role	Organization Name	First Name	Last Name	E-mail Address	Backup E-mail	Mobile Phone
Lead	Internal
Alternate Lead	Internal
Coordinator	Internal
Internal PR/Media	Internal
Outside Breach Counsel
Forensics and Incident Response Vendor
Information Technology (“IT”) Vendor
Managed Security Services (“MSS”) Vendor
Cyber Strategy Vendor

Other Relevant Contacts

Role	Organization	Contact First Name	Contact Last Name	Contact E-mail	Contact Phone	Notes
Cyber Insurance Vendor						Policy Number:

Purpose/Overview

This Incident Response Plan provides a framework for identifying and responding to cybersecurity-related incidents that occur within our organization. We recognize that every incident will be unique and provide its own challenges. Therefore, unlike our policies and procedures, the steps below are not intended to be proscriptive. They are meant to provide a structured approach through which the incident response team can address any given incident. Deviations from the plan are authorized where necessary or appropriate and authorized by the Lead, Alternate Lead, or Coordinator , but must be documented.

Plan

1. Preparation

• a. Make Copies of the Plan Available - Although a master copy of this Plan will be stored in electronic form with the Organization’s other policies and procedures, the Coordinator will also maintain a sufficient quantity of paper copies at the Organization’s offices such that the entire Team can have copies in the event the Organization’s systems are, or must be taken, offline. All Team members will also store electronic copies of the Plan outside the Organization’s systems for their reference.

Detection and Analysis

• a. Determine Whether an Incident has Occurred
• i. Collect Background Information - Record contact information for the person reporting the Incident (the ’ Incident Reporter ’), the contact information for the Coordinator, the date and time the Incident was first reported, and, where available, the date and time the Incident was first discovered, on a copy of the Client Data Breach Incident Response Worksheet (the ‘Worksheet’). A copy of the Worksheet can be found in FutureFeed under the Technology subway stop. Record the details provided by the Incident Reporter in the Incident Details section of the Worksheet. Mark the Incident as Under Investigation by placing a check mark next to Investigating under the Incident Details section of the Worksheet.
• ii. Basic Actions Based on Incident Type - The appropriate next steps will vary based on the type of Incident that has been reported.

1. Stolen Physical Property Containing Client Data - If the Incident involves the theft of physical property (e.g., the theft of a laptop, server, portable media, physical files, etc.) as reported by a Organization employee, contact local law enforcement immediately and record the contact information for the primary and alternate law enforcement officer(s) on the Worksheet. Record the date and time at which the Incident was first discovered and reported in the Incident Details section of the Worksheet. Record the address from which the physical property was stolen in the Incident Started field of the Incident Details section of the Worksheet, and the addresses from which the incident was first discovered and first reported in the corresponding fields in the Incident Details section of the worksheet. These facts are sufficient to determine that an Incident has occurred, and you should proceed to 2)b., below.

2. IT Vendor, MSS Vendor, and Organization Employee Reports - If the Incident Reporter is the IT Vendor and/or the MSS Vendor , record the IT Vendor and/or MSS Vendor contact information in the Other Team Members Involved section of the Worksheet. Work with the Incident Reporter to fill in as many details as are available in the Incident Details section of the Worksheet. An Incident report by the IT Vendor, the MSS Vendor, or a Organization employee is sufficient to determine that an Incident has occurred and you should proceed to 2)b., below.

3. Internally Maintained Software - If the Incident Reporter is an internally maintained tool and that tool identifies a potential data breach, you should:

• a. Make two copies of any log files associated with the tool and any recent reports generated by the tool.
• b. Store one of the log file copies in a safe place, preferably off-site.
• c. Record as many details as are available in the Incident Details section of the Worksheet and continue to 2)b, below.

4. Reports from Law Enforcement or Regulators - If the Incident Reporter is or purports to be a law enforcement officer or regulatory official:

• a. Record the physical location involved in the report in the appropriate field in the Incident Details section of the Worksheet, if relevant and available.
• b. Record the contact information for the Incident Reporter in both the Incident Reporter and Primary Law Enforcement Officer/Regulator fields on the Worksheet.
• c. Record the Incident Reporter’s supervisor’s information in the Worksheet;
• d. Independently verify the supervisor’s contact information (e.g., by calling a publicly-available telephone number for the organization employing the Incident Reporter and supervisor and validating that they are employees and their contact information).
• e. Initiate contact with the supervisor to ensure that the report is legitimate.
• f. If the supervisor confirms the details in the report, record this information in the Response Actions Performed section of the Worksheet. The supervisor’s confirms of the details is sufficient to determine that an Incident has occurred and you should proceed to 2)b.
• g. If the supervisor does not confirms the details, record the time and date of the conversation and the fact that the supervisor was unable to corroborate the report in the Response Actions Performed section of the Worksheet. You should consult with the Lead to determine whether to stop the response at this point, or to further engage actual law enforcement or regulatory personnel.

5. Reports from Independent Security Researchers - If the Incident Reporter is or purports to be an independent security researcher (e.g., a ‘white hat hacker’ or ‘ethical hacker’), their report may include a request for compensation and a timeline for response before the Incident is publicly disclosed. This is a standard industry practice in the ethical hacker community and should not be viewed by the Organization as an overtly aggressive act. The Incident Reporter chose to disclose the Incident to the Organization in a constructive manner (i.e., without notifying the media or

authorities) that allows the Organization to decide how best to proceed. The Incident Reporter’s disclosure of the Incident in this manner will likely save the Organization significant costs over alternative disclosure methods that could have been used.

• a. Record the nature of the report (i.e., that it was disclosed by an ethical hacker) in the Incident Description portion of the Incident Details section of the Worksheet along with all details provided by the Incident Reporter .
• b. Using information from the report, fill in as many details as are available in the Incident Details section of the Worksheet, but do NOT contact the Incident Reporter for additional details.
• c. The Organization will endeavor to reply to the Incident Reporter within one (1) business day with: a) a confirms of receipt; and b) an assurance that the report is being processed through internal channels and that the Organization will provide an additional reply within one (1) business week. The foregoing response should be sent by the External PR/Media contact, except where the External PR/Media contact is unable to respond within the reply timeline specified in the previous sentence in which case the Internal PR/Media contact must reply within the aforementioned timeline.
• d. Log the contact information for the person responsible for replying to the Incident Reporter in the Other Team Members section of the Worksheet. Record the actions taken in the Response Actions Performed section of the Worksheet, including the date(s) and time(s) that the Team Members were notified of the need for a reply, the person replying, the content of each reply, and the content of each reply.
• e. Proceed to 2)b., below, after initiating the reply process and logging the appropriate information in the Worksheet.

6. Other Reports - If the Incident Reporter is any other third party, additional, independent corroborating information will be needed before an Incident should be declared. You should fill in as many details as possible in the Incident Details section of the Worksheet and proceed to 2)b.

b. Collect Relevant Impact Factors

• i. Mark Incident Status - Place a check mark next to the Ongoing Attack and Investigating status indicators under the Incident Details section of the Worksheet.

• ii. Identify the Affected Resources - List the resources (networks, subnets, hosts, etc.) in the Affected Resources section of the Worksheet. Supply the IP address(es), functionality (e.g., E-mail server, external accountant, end-user workstation, copier, etc.), and equipment name(s) for each affected resource.

• iii. Identify the Information Involved - Identify the type(s) of information that may have been stored, processed, or transmitted by the affected resource(s) in the Information Types Impacted table. Indicate the jurisdiction(s) of the data subjects (i.e., those individuals about whom the information pertained) and the data owner(s).

• iv. List Known Attack Vectors and Indicators of Compromise - Collect information regarding how the incident occurred or was identified, and any indicators of compromise.

• c. Quantify Incident Impact

• i. Use the Impact Quantification Factors worksheet to assign a Severity Score to the Incident.

d. Declare Incident and Report to Appropriate Personnel

• i. If the Incident may affect Covered Defense Information or the organization’s ability to perform the requirements, designated as operationally critical support and identified in a contract containing DFARS 252.204-7012, the Lead shall:
• i. Conduct a review for evidence of compromise of covered defense information. Such review shall include, but is not limited to identifying potentially compromised:
• i. computers
• ii. servers
• iii. specific data and
• iv. user accounts
• ii. Report the Incident to DoD at https://dibnet.dod.mil
• iii. Treat the Incident-related information that relates to systems handling the Covered Defense Information as information created by or for DoD and ensure all elements required at https://dibnet.dod.mil are incorporated in that information.
• iv. Perserve and protect images of all known affected information systems and all monitoring/packet capture data for at least 90 days from the submission of the cyber incident report to allow DoD to requiest the media or decline interest.
• v. If the Incident leads to the discovery or isolation of malicious software, the Lead shall ensure that the malicious software is submitted to the DoD Cyber Crime Center (“DC3”) in accordance with instructions provided by DC3 or the Contracting Officer, and shall ensure that the malicious software is not sent to the Contracting Officer.
• ii. Examine the Severity Score of the Incident.

1. If the Incident is determined to be a Critical or High incident, contact the Lead and alert the Lead of the severity. The Lead shall contact Outside Breach Counsel immediately and will contact the Coordinator . Skip ahead to 2)d.ii.
2. If the Incident is determined to be a Moderate or Low severity, contact the Coordinator immediately and advise the Coordinator of the Incident and the Severity Score. The Coordinator should determine, with input from the Lead , whether to involve Outside Breach Counsel at this time.

• iii. Identify Relevant Jurisdictions and Determine Breach Notification Window. Many jurisdictions require that an organization experiencing a data breach notify the State Attorney General or other individuals within a specific time period. It is important to ensure that the Incident response meets these legal and regulatory requirements.

Containment, Eradication, and Recovery

• a. Contain the Incident - Containing the incident is an important part of an incident response. In some cases, it may be prudent to disconnect the equipment from the network or shut down the equipment to help contain the incident. However, such actions may cause the loss of important evidence that could help identify the perpetrator, while delaying such actions may result in significantly more data loss. The Lead is authorized to make the final decision as to whether to prioritize shutting down the equipment over preserving data. In general, if the Severity Score is Critical, the Lead should prioritize shutting down the equipment to prevent additional loss. If the Severity Score is High or

Moderate, or if the Incident is continuing to spread, the Lead should prioritize disconnecting the impacted equipment from the network. If the Severity Score is Low, the Lead should prioritize preserving evidence. Document the steps taken to contain the Incident in the Response Actions Performed section of the worksheet below.

4. Acquire, Preserve, Secure, and Document Evidence - Ensure that, where possible, log files and memory dumps from relevant equipment are preserved and copied to removable media. That removable media must be carefully labeled so that others are aware that it: a) contains critical information, and b) may be infected by whatever is causing the Incident. All efforts taken to maintain the evidence should be documented in the Response Actions Performed section of the worksheet below.

Eradicate the Incident

• a. Identify and mitigate all vulnerabilities that were exploited. This may involve the removal of equipment, updating of hardware/software, or other actions.
• b. Remove malware, inappropriate materials, and other components added by the attackers during the Incident.
• c. If more affected equipment is detected, repeat detection and analysis procedures to identify any other potentially affected equipment before repeating the containment and eradication processes.
• d. Recover from the Incident
• i. Implement additional monitoring, as needed, to look for future related activity.
• ii. Return Affected Systems to Operationally Ready State. Returning to the Operationally Ready state too soon could result in reinfection or additional issues. The Lead is solely authorized to determine when equipment is ready to return to the Operationally Ready state.
• iii. Confirm that affected systems are functioning normally. Record all findings in the Response Actions Performed section of the worksheet below.

Post-incident Activity

• a. Gather Additional Evidence - Record any additional information, including any comments and notes from those involved in responding to the Incident, in the Post Incident Analysis section of the worksheet. This includes identifying those attributes of this Incident Response Plan that went well and those that need adjustment.
• b. Create Follow-up Report - A follow-up report should be created which documents actions that have and will be taken to reduce the likelihood of similar events occurring in the future.
• c. Hold Lessons-learned Meeting and Update Incident Response Plan - A meeting should be held with all Team members to discuss what went well and what could use improvement. That information should be consolidated and used to update this Incident Response Plan.

Related Standards, Policies, Plans, and Procedures

[Insert list of other, related standards, policies, plans, and procedures]

Revision History

2026-08-20 — Darren Rush

Merge pull request #2 from safire-dev/dev (16cb681)

Edit this Page