August 25, 2021

Incident Response Policy Example

Hello all! I was recently tasked with performing an IR Policy uplift at my organization, and wanted to share an anonymized version of it here! 90% of the formatting survived, so feel free to use (or critique) it if you’d like!

It’s mostly based on NIST 800-61, with some of the SANS incident lifecycle and Verizon VERIS categorizations thrown in, and should be useful for medium-low maturity organizations such as my own.

Throughout the document “VVVV” was used to redact the company name, you should be able to find\replace with your own company name if needed. Otherwise, if you have questions ask away!


**VVVV Information Security Incident Response Policy**

**1.** **Incident Response Policy Overview**

This document formally defines the goals and expectations that VVVV personnel will execute upon while responding to threats to the organization.

This Policy draws heavily from the industry best-practice NIST framework, as defined in [NIST SP-800-61 Rev. 2]( written and published by the U.S. Department of Commerce.

Topics covered in this policy include:

· Defining the terms: *Incident*, *Impact*, and *Severity*

· Incident Response lifecycle, Incident categorization

· Escalation process and relevant stakeholder roles

· Communication requirements, frequency

· Incident Response policy maintenance

Ultimately, the objective of the Incident Response program is to respond quickly and effectively to threats which have the potential to disrupt Confidentiality, Availability, Integrity, and Non-repudiation of business-related activities.


**2.** **Common Language and Definitions**


Event – Any observable occurrence in a system or network

Alert – An event which has been flagged by a security control, either automatically or manually, to be reviewed by the information security team

Incident – An investigation of an alert that contains notes, observations, and actions taken by an incident responder

Types – Security Incidents are categorized in the following ways:

Malware – evidence of malicious code execution

Environmental – infrastructure issues such as power, cooling, weather

Physical – asset is physically stolen, damaged, or handled incorrectly

Error – Config errors, such as unpatched vulnerabilities, poor practices

Misuse – Evidence of intentional or unintentional asset misuse

Social – situations involving phishing, or other deceptive attacks

Hacking – active, advanced attacks, or 3rd party breach requiring action

Severity – A measure of the functional and informational impact of an incident, as well as the effort required to recover from a successful attack.

Critical – Requires formal execution of the Incident Response Plan, potentially engaging 3rd parties such as Incident Response, Legal, or Insurance retainers

· Functional: The widespread inability of the organization to provide any critical services to users

· Information: Confirmed data exfiltration of either proprietary or personally identifiable information.

· Recoverability: Recovery from the incident is not possible

High – Escalated threat with confirmed impact, requires stakeholder communication

· Functional: The organization has lost the ability to provide a critical service to a subset of users

· Information: Suspected data exfiltration of either proprietary or personally identifiable information

· Recoverability: Time to recovery is unpredictable, additional resources and outside help are needed

Medium – Potential for future impact, or confirmed but very limited impact

· Functional: The organization can still provide all critical services, but at reduced efficiency

· Information: Potential data exfiltration of non-critical information

· Recoverability: Time to recovery is predictable with normal effort

Low – No impact, events that may result in future higher severity incidents

· Functional: No effect on the organization’s ability to provide all services to all users

· Information: Zero data exfiltration

· Recoverability: Time to recovery is known and trivial to execute

Major and Minor Incident Classification

*Major* *–* Incidents with a severity of *Critical* or *High* are classified as *Major* Incidents. These Incidents usually require significant investigative and analysis work from CSIRT. Major Incidents typically involve multiple teams, regular communications to leadership and the business, and require post-incident analysis of the handling of the Incident to identify process gaps or recommendations to prevent similar Incidents in the future.

*Minor* *–* Incidents with a severity of *Low* or *Medium* are classified as *Minor* incidents. These Incidents are usually well understood and have pre-defined procedures for successful handling. Communications and escalations stay within the Information Security team. Minor incidents are limited to little-to-no impact to everyday operations.

Incident Lifecycle– These 6 distinct phases describe the current status of an Incident

Preparation – The act of defining an Incident Response process before an incident occurs. Communication templates, authorized actions, stakeholder contact information, runbooks and procedures, are defined and agreed upon.

Identification – The collection and documentation of data for an ongoing Incident, such as the collection of logs, assets, or indicators of compromise

Containment – Taking action to prevent further damage from occurring as a result of an Incident.

Eradication – Taking action to remove or eliminate malicious artifacts that were identified during an Incident.

Recovery – Taking action to restore impacted assets back into normal operation safely.

Lessons Learned – Post-incident review defining gaps in existing controls, recommendations for changes to existing controls, or general process failures.


**3.** **Computer Security Incident Response Team (CSIRT) Stakeholder Roles**

This section defines the relevant roles that are required for a mature Incident Response program to succeed. These range from roles involved with the actual processing and handling of an Incident, to leadership roles involved with decision making and communications.

These roles are summarized below, see Detailed CSIRT Role Definitions for information about specific role responsibilities, how and when they are assigned, and detailed interactions.

📷 *Figure 1- Example of role interactions for a Major Incident*


The *Coordination team* members are responsible for ensuring appropriate procedural steps are taken throughout the response activities. This includes tracking observables, ensuring all detections are thoroughly investigated, and managing communications outside the response team.

· Incident Commander – Directs tasks, assigns roles, may handle communications, responsible for completion of post-incident activity, overall owner of an Incident

· Incident Communications Coordinator *–* dedicated to handling notifications and all communications with IT, Extended CSIRT, and other stakeholders.

· Evidence Curator – Collects, stores and documents evidence.


The *Response team* is responsible for performing investigative steps and actually implementing, containment, eradication, and recovery procedures. The Response team includes Security Analysts, Operational subject matter experts, and other IT staff.

· Analyst – Performs threat impact analysis, examines digital forensics data.

· Technical Responder – Completes tasks and activities during Incident Response

· Working Group Coordinator – Special role for some IR events which provides a bridge between Coordinator and Responder teams. This role is only assigned if an Incident has a high degree of complexity, and reports to the Incident Commander.

The *Response team* must have privileged (Read\Write\Execute) access to all VVVV assets in the event that they need to interact with systems during an investigation. Usage of this access must be highly auditable, and utilize accounts created specifically for this purpose (separate from responder’s everyday accounts)

The *Response team* must also have the authority to *Contain* an incident to prevent further damage to the organization, even if it causes impact to critical service availability. Containment situations which will cause known impact must follow the “Critical asset containment approval” process.

Incident Responders must maintain adequate training so that they remain qualified to perform their duties. Specialized training should occur annually, and include topics such as Cybersecurity best practices, enterprise incident response, threat hunting, vulnerability detection, digital forensics, relevant tool certifications, and cover common terminology.

Extended CSIRT

The *Extended CSIRT* consists of various members of the business who have a vested interest in maintaining normal operations for the organization but are not directly involved with the processing of an Incident. This includes C-Suite, Business owners, HR, Legal, Insurance and Incident Response retainers. Members of the Extended CSIRT are defined in the Extended CSIRT matrix

The responsibilities of the Extended CSIRT typically involve decision making regarding 3rd party involvement, such as activating retainers, notifying law enforcement, breach disclosures, and adherence to regulatory and privacy requirements.



**4.** **Security Incident Communication Plan**

In the event that a *Major* Incident is declared, appropriate communication mechanisms are defined below to allow information to be delivered to relevant stakeholders.

Communication Channels

*Email systems* – To be used for both regular and ad-hoc incident updates to CSIRT

*Phone systems* – Suitable for incident coordination, specific knowledge sharing

*In-person* – A secure space, such as a “War room” must exist to allow incident specific knowledge to be shared confidentially.

*ServiceNow* – Instructions assigned to the Response team to aid in the containment and recovery during an Incident

*Website* – Notice of outage, both internally and externally facing must be prepared

*Out-of-band communications* –

Can be used to notify the Incident Response team, of new\ongoing Incidents and allow coordination to set up in-band communications.

Communication Types

**Milestone Communication** – Upon the declaration of a *Major* Incident, Regular pre-formatted emails to CSIRT will be delivered which provide current incident status and recovery ETAs

*Format requirements*: Milestone communications must use a specific format, and be sent to (CSIRT email distribution group), flagged ‘important’. See Milestone Communication format procedure for specifics.

*Schedule*: Milestone communications must be sent every 1 hour (critical) 4 hour (high) until the incident is resolved

**Ad-Hoc Communication** –

Ad-Hoc communications are typically reserved for on-demand updates to CSIRT, Incidents which do not require an hourly update schedule, or as supplemental updates to be delivered to specific stakeholders between Milestone communications. Because of this dynamic nature, Ad-Hoc communications do not have a strict formatting requirement and tend to contain more granular detail for the Incident.

**Verbal Communication** –

In-Person communication should be restricted to a ‘need-to-know’ basis and should be shared with the minimum number of people necessary to work the Incident. The level of discretion is determined by the Incident Commander.

All Information Security incidents have the potential for VVVV employees to testify in a court of law, a fact that should be understood by all parties whenever handling particularly sensitive data, as defined in the VVVV information classification standards

War room – An effective method of ensuring that only those necessary to work an Incident is to secure a physical space with guaranteed availability, with the ability to privately display sensitive information to those involved in an Incident.

Primary Incident handler – Upon identification of an Incident, an *Incident Commander* must be chosen. All new information relevant to the incident must originate from, or involve, the *Incident Commander*. Doing so reduces the risk of undue speculation and can prevent uninformed decisions and double work.

Phone – When an Incident is identified, the CSIRT must have the option to discuss the situation with any stakeholder as necessary. The contact information for all stakeholders is defined in the CSIRT Communications Matrix

Teleconferencing Bridge – A dedicated teleconferencing line must be available for use, with the ability to add\remove participants as necessary to run the Incident.

Out-of-Band Communications – The CSIRT must have non-VVVV methods of contacting each other if all VVVV assets are deemed unsafe. Ex. Personal Cell\email

**Website** –

VVVV must prepare, in advance, a service interruption webpage to use if an Incident with impact occurs which affects the availability of critical services. The language of this email must be reviewed and approved by the corporate communications and legal teams. The CIO must decide when this service interruption webpage is enabled.

**ServiceNow** –

Some incidents require action from the broader IT response team. These IT resources utilize ServiceNow to track, prioritize, and document requests until they are resolved. Information shared via ServiceNow *must* be non-confidential, as the tool does not limit access to view tickets for those who have general access to the system.


**5.** **Incident Response Plan Maintenance**

This incident response plan must receive regular updates from CSIRT to remain effective. These updates should originate from the availability of new technologies, lessons learned from Incident Response, and tabletop exercises.

Frequency: CSIRT must meet at least once annually to review the IR plan.

Method: All changes to the Incident Response plan need to be documented and approved via the ITIL Change process.


IR Tabletop: CSIRT must perform an annual tabletop exercise to remain familiar with the Incident Response Plan and identify any deficiencies that need to be addressed. The IR tabletop scenario should be chosen by the *Information Security Manager* and be shared with as few people as possible to perform the simulation.

Throughout the Incident, CSIRT is to exercise their authority to procure the designated War Room, contact relevant support personnel, and test other various escalation and recovery procedures.

CSIRT Organization Change: Should an organization change which modifies the CSIRT stakeholders occur, the updated information should be immediately updated in the CSIRT Contact List.xlsx

Annual Lessons Learned Review: The Incident Response team must complete an annual meeting to review the *lessons learned* phase of all Major Incidents, to determine if the IR plan should be modified to better handle similar incidents in the future. Examples of changes which might originate from this review include:

· Security Policy changes

· Security awareness program changes

· Software reconfiguration (configuration error remediations)

· Deployment of missing security controls

· Reconfiguration of existing security controls



If anyone has questions, I’d be happy to answer!


Leave a Reply

Your email address will not be published. Required fields are marked *

Note: By filling this form and submitting your commen, you acknowledge, agree and comply with our terms of service. In addition you acknowledge that you are willingly sharing your email address with AiOWikis and you might receive notification emails from AiOWikis for comment notifications. AiOWiksi guarantees that your email address WILL NOT be used for advertisement or email marketting purposes.

This site uses Akismet to reduce spam. Learn how your comment data is processed.