No matter how well you maintain your security posture, you cannot guarantee 100% protection against an attack on your IT systems. That's why it's so important to adopt a wider approach to cybersecurity by focusing on resilience rather than simply prevention.
If the unthinkable should happen, you need to act quickly and halt the spread of an attack before it causes further harm. Then you need to get your systems back up and running as fast as possible to minimize the disruption to your business.
However, security personnel will be under intense pressure to contain and remediate the threat and could easily become overwhelmed and make costly mistakes. Furthermore, your legal department will need to hit the ground running to ensure you comply with regulatory requirements, And communications teams will need to pull out the stops to get their messaging right to staff, customers, shareholders, and the wider public.
It's essential everyone involved in the incident response process be fully prepared in advance so they can calmly go about their tasks in a competent and efficient manner. In other words, you need a carefully planned, comprehensive incident response strategy.
But how exactly do you begin such a complex undertaking? And how do you get senior management on board with your incident response initiative?
That's what an incident response policy sets out to achieve.
So, in this article, we discuss the purpose of such a document, explain why it's important and provide you with a template for creating your own company incident response policy.
Quickstart Cloud Incident Response Template
The only IR plan template on the web built with the cloud in mind.
Download Template
What is an incident response policy?
An incident response policy is a document that shapes the way your company prepares for and responds to a suspected or confirmed security incident.
It is a rallying call for making response planning a primary objective within your organization and should be presented to and approved by the leadership team. This helps achieve buy-in from senior management, strengthen accountability and give you the authority to move forward with your incident response strategy.
Above all, it should serve as a broad blueprint for managing the incident response lifecycle, providing the stepping stone for more detailed documentation for handling an incident.
This deeper, more specific material typically takes the form of an incident response plan and a series of incident response playbooks, where:
The incident response plan expands upon the roadmap set out in your incident response policy with much more detail on preparation for, management of, and improvements to be made following an incident
Each incident playbook is a standardized set of procedures you should follow in response to a particular type of incident, detailing actionable steps you need to take at each stage of the response process along with the tools you'll need to perform each task
Incident Response Policy Template Checklist
The following template provides a framework for creating your own incident response policy. But every organization is different. So bear in mind that you'll still need to add or remove statements and sections to suit your own specific business and operational needs.
11. Business continuity and disaster recovery
1. Introduction
Your introduction should resonate with senior decision makers. So it should take a wider view of incident response by explaining the following:
Why incident response is so important, putting both the technical and business case for an incident response strategy
The purpose of the policy, why it was created and whom and what it applies to
Your introduction should also include:
At least one statement that demonstrates your organization's commitment to security
A mandate for the creation of an incident response plan and detailed playbooks—ideally with a timeline for creating them
The position within your company of the person who will be responsible for enforcing the policy
2. Technology
Cybersecurity is a complex discipline with a specialist vocabulary of terms and concepts that aren't widely understood. To ensure everyone shares a common language and prevent time-consuming misunderstandings, your policy should:
Set out clear definitions for terms, such as vulnerability, threat, attack, event, incident, personal data, and different types of data breach
3. Roles and responsibilities
You should explain the scope of your policy in terms of whom it should apply to and use it as the first step towards building your incident response team. For example, you should state you need to:
Set up a cyber incident response team (CIRT)
Designate an incident manager who will head up the team overall
Identify backup personnel who can step in if the incident manager is unavailable
Nominate those who will be responsible for developing your incident response plan
Decide whether you need the services of a third-party security provider
Wiz enhances real-time threat detection and response capabilities to stop threats from becoming incidents
Read more
4. Communications
This section will set the direction for your communication strategy and should state you need to:
Establish designated points of contact
Define primary and secondary methods of contact—typically email, phone, and messaging apps
Set out procedures for incident reporting and triaging cases
Identify who will be responsible for notifying enforcement bodies in line with compliance requirements
Draw up a list of all other parties you should inform in the event of an incident, such as customers, suppliers, insurers, law enforcement, and partner companies that form part of your software supply chain
Develop an external communications (PR) plan
Outline responsibilities for reporting progress throughout the response process
5. Training
As part of your commitment to security, your policy should set out plans for training across all aspects of preventing and responding to attacks. It should typically cover:
Basic security awareness training
In-depth technical training for cybersecurity teams
Training on how to use tools and technologies for detecting, analyzing and flushing out attacks
Compliance training
Dedicated incident management training
6. Regulatory Compliance
Your organization will need to meet the incident reporting requirements of a range of different data protection regulations and standards. While these share much in common, legal and communications teams will need to be aware of the differences. For example, some state very clear time limits for reporting a breach after it has become known. By contrast, others merely state that you should do so within a reasonable time.
Under the terms of your policy, your organization should therefore look to establish:
What regulations and standards apply to your organization
What types of data they apply to
Requirements for notifying enforcement agencies in the event of an incident
Requirements for informing individuals affected by the breach
Whom you must contact and by what method
7. Asset Inventory
Your asset inventory will help define the scope of your policy in terms of what it applies to. It will also give you a wider picture of your systems and the relationships between them. This can prove invaluable to incident response teams by helping them to understand more clearly what and who has been affected by the breach and identify potential avenues for lateral movement of the attack.
You should therefore propose that your organization:
Draw up a preliminary list of the IT assets you need to protect
Map your inventory in more detail, including the relationships between different systems
Use your mapping exercise as the basis for setting priorities for incident response and recovery—based on factors such as service-level agreements (SLAs), potential loss of revenue, and compliance requirements
Detail your findings in your incident response plan
8. Threat models
Different types of attack necessitate different types of response. So it makes sense to include provisions for identifying and listing the different types of threat to your systems. You should then recommend threat modeling techniques to help you understand the nature of each such threat, documenting basic information such as the:
Risk it poses to your data and organization as a whole
Likely goal of an attacker
Resources you need to deal with the attack
Most suitable response procedure
9. Security tooling
You should recommend a review of existing security tooling for managing incident response—with the view to procuring additional tools where necessary.
Your policy should make reference to the different types of solution that offer incident response capabilities. These typically include:
Endpoint detection and response (EDR)
Cloud detection and response (CDR)
Extended detection and response (XDR)
Security information and event management (SIEM)
Security orchestration, automation and response (SOAR)
10. Detection and remediation
This section should give a brief technical overview of the incident response process and should cover:
Detection: Evaluation of potential signs of an attack to determine whether a security incident has occurred or is about to occur
Analysis: The investigation phase to determine the root cause of the attack, the likely impact on your deployments, and appropriate corrective action
Containment: Technical measures to minimize the spread and impact of the breach
Eradication: Procedures for eliminating the threat, such as removing malicious content, patching vulnerabilities and blocking points of entry
Recovery: The series of coordinated steps for restoring your systems to their previous state—without opening the door to a repeat attack
11. Business continuity and disaster recovery
Business continuity (BC) and disaster recovery (DR) focus on keeping mission-critical operations running during a period of disruption, such as a cyberattack, and restoring systems to normal with the minimum of downtime and impact to your business. BCDR plays a key role in incident response and the two should therefore work together in harmony. Hence you should call upon your organization to:
Outline measures for coordinating your response with the BCDR team
Make use of common elements in your BCDR plan, such as processes, roles, and responsibilities, and integrate them onto your incident response plan
Include brief guidance about when to trigger BCDR responses depending on the stage you're at in the incident response process
12. Review cycle
Finally, your policy should require that you:
Periodically review incident response plans and playbooks to reflect changes to your environments
Update them after an incident with lessons learned from the response team's experiences
Detect, Investigate, and Respond to Cloud Threats
Continuously monitor your cloud workloads for suspicious activity and collect intelligence from cloud providers to proactively detect and respond to unfolding threats.
Learn moreHow Wiz Helps with Incident Response in the Cloud
Wiz provides a suite of features that can assist with the Identification, Containment, and Eradication steps of an IR plan, including:
Detection and Analysis:
Cloud Activity Monitoring: Wiz integrates with cloud provider activity logs (e.g., AWS CloudTrail, Azure Activity Logs) to collect data and provide context for security risks identified by its security graph.
Threat Detection and Prioritization: Wiz continuously monitors cloud workloads for suspicious activity and leverages threat intelligence to detect and alert on potential threats.
Attack Path Analysis: Wiz's Advanced Control feature automatically analyzes potential attack paths across your cloud environment, helping you prioritize threats based on their potential impact.
Containment and Eradication:
Investigation and Forensics: Wiz provides container forensics and runtime execution data to help you investigate incidents and understand their potential blast radius.
Response Playbooks: Wiz offers pre-built and customizable response playbooks for common cloud threats, allowing you to take quick action to contain and eradicate threats.
Wiz aims to empower security teams by offering a comprehensive Cloud Detection and Response (CDR) solution that streamlines the incident response process, allowing them to:
Reduce alert fatigue: By prioritizing threats based on context and potential impact.
Shorten investigation time: Through efficient tools for gathering evidence and understanding the scope of the incident.
Take quicker action: With pre-built playbooks and automated response capabilities.
Empower IR in the Cloud
Learn why IR teams rely on Wiz to respond to security incidents in their cloud environments faster and more efficiently.
