Security Incident Response Plan (SIRP) Template

The SIRP ensures that you can quickly respond to and recover from security incidents.

Last reviewed and updated: [date]

Owner: [Full Name]

Responsible Team: [Department/Business Unit Name]

Purpose

The aim of establishing an Incident Response Plan is to provide the organization with appropriate capability for assessing, responding to and learning from information security incidents, and providing the necessary coordination, management, feedback and communication.

Main Objectives and Activities

1. Manage integrated security systems: monitor information security event management services installed on systems in scope (e.g. intrusion detection system, intrusion prevention system, firewall, network resource, etc.)
2. Implement a consistent plan: minimize risks to the information system by applying a consistent set of response tasks
3. Respond promptly: define the most appropriate detection and response mechanisms to react quickly to threats, breaches, and attacks to minimize damage and reduce cost of recovery
4. Debrief and post incident analysis: determine which parts of the incident response plan worked successfully and identify any improvements that are required.

1. Roles and Responsibilities

2. Detection and Reporting of Events/Incidents

3. Responding to Events/Incidents

When dealing with a reported event, alert or an incident, the following actions are followed, formally tracked and documented within [link to ticketing system]:

1. Respond to and assess the event/incident
   1. Determine what happened and how it occurred
   2. Identify if and which parts of the organization and interested parties have been affected
   3. Try to anticipate the duration of the incident and the likely impacts
   4. Assess whether the incident will be managed by routine management arrangements
   5. Judge by reference to pre-defined thresholds whether the incident could lead to disruption
2. Manage the immediate consequences of the incident, considering options for responding to the incident, and preventing further loss or damage
3. Declare an incident and activate the procedures when activation criteria have been met
4. Establish a central location for use by the team managing and controlling the incident (e.g. Slack Channel)
5. Prioritize issues and activities to be undertaken in managing the incident and its impacts
6. Control and coordinating all activated procedures
7. Monitor the incident as it progresses
8. Review and adapt plans in response to changing circumstances
9. De-escalate, stand down and return to routine operations as sustainable capability is reestablished

4. Debrief and Post Incident Analysis

As a part of post-incident resolution, the incident coordinator reviews all that has happened to assess and quantify the effectiveness of the entire response to the information security incident. The analysis helps determine which parts of the incident response plan worked successfully and identifies any improvements that are required.

The important aspect of post response analysis is to feed information and knowledge back into the incident response process. If an incident is sufficiently severe, the incident coordinator ensures that a meeting of all the relevant parties is scheduled shortly after its resolution while information is still fresh in people's minds. Factors covered in the meeting include the following:

1. Did the procedures outlined in the security response process work as intended?
2. Are there any procedures or methods that would have aided in the detection of the incident?
3. Were any procedures or tools identified that would have been of assistance in the response process?
4. Were there any procedures that would have aided in recovering information and systems following an incident identified?
5. Was the communication of the incident to all relevant parties effective throughout the detection, reporting and response process?

The results of the meeting are documented. The organization ensures that the areas identified for improvement to the incident response plan are reviewed and justified changes incorporated into an update of the plan documentation. 

5. Information Security/Data Breach Reporting  

A breach is a compromise of information security that leads to the undesired destruction, loss, alteration, disclosure of, or access to, protected information transmitted, stored or otherwise processed. 

If a breach occurs, immediately contact the Security Incident Coordinator and Manager, who will: 

1. Open a ticket to formally document and track within [link to ticketing system]. 
2. Immediately alert and schedule a meeting with the Head of GRC, VP of Product and Head of Engineering, to relay what has occurred and what steps have been taken to contain the breach. 

After containment of the breach, a thorough forensic investigation will be conducted to determine the extent of the breach and what customers have been impacted. These results, if needed, will be communicated to the VP of GTM and Operations, to notify impacted external stakeholders (investors, customers etc.). See “Data Breach Reporting Table” below. 

NOTE: [Company Name] does not store ePHI or PCI DSS data, and encourages clients to follow data minimization principles, by only uploading data into their [Company Name] account that is required for the audit.

Data Breach Reporting Table

Appendix A: Breach Risk Assessment Form

Breach means the acquisition, access, use, or disclosure of confidential or sensitive (protected) information in a manner which compromises the security or privacy of the protected information.

An acquisition, access, use, or disclosure of protected data is presumed to be a breach unless [Company Name], demonstrates that there is a low probability that the protected health information has been compromised based on a risk assessment of at least the following four factors:

Breach Risk Assessment Table

*Risk: Use probability scoring of 1 (lowest) to 5 (highest) to determine the probability that the data has been compromised.

NOTE: Breach Exclusions:

1. Any unintentional acquisition, access, or use of data by a workforce member or person acting under the authority of [Company Name], if such acquisition, access, or use was made in good faith and within the scope of authority and does not result in further use or disclosure.
2. Any inadvertent disclosure by a person who is authorized to access data, to another person authorized to access data at [Company Name], and the information received as a result of such disclosure is not further used or disclosed.
3. A disclosure of data where [Company Name] has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information.
4. An acquisition, access, use, or disclosure of data is presumed to be a breach unless [Company Name], as applicable, demonstrates that there is a low probability that the protected information has been compromised based on a risk assessment of at least the four identified factors above.

Appendix B: Notification to Stakeholders

This outlines the requirements to be provided without unreasonable delay and no later than 60 calendar days after breach discovery date to [Company Name] listed stakeholders in “Data Breach Reporting Table” above:

1. The identification of each individual whose unsecured protected data has been, or is reasonably believed by the business associate to have been, accessed, acquired, used, or disclosed during the breach. 
2. Date of the discovery of the breach
3. A brief description of what happened
4. A description of the types of unsecured protected data that was involved in the breach
5. A brief description of what is being done to investigation the breach and to protect against further breaches