7 common mistakes companies make when creating an incident response plan and how to avoid them

Cisco Talos recently covered the basics of NIS2, a new set of requirements for cybersecurity and security incident disclosures set to take effect next year in the European Union.

As part of these new guidelines, organizations with operations in the EU must have up-to-date “incident handling” procedures and “policies on risk analysis and information system security”

To comply, Talos IR recommends creating or updating your organization’s incident response (IR) plan, along with the Information Security Policy, Business Continuity and Crisis Management Plan. The IR plan is a crucial document for each organization’s cybersecurity practice and should be among the first documents to be updated to comply with NIS2.

Below, we’ll outline seven common pitfalls that organizations make when creating or updating an incident response plan. Avoiding some of these common mistakes ensures your organization’s plan will be updated faster and is more thorough, so you are ready to act when, not if, an incident happens.

Part II: Pitfalls to avoid when creating an incident response plan

Failing to define a document hierarchy

A common mistake when starting to work on a new or updated IR plan is to look at the plan in isolation, without consideration for all the cybersecurity documents that exist in your organization.

The term “document hierarchy" might sound complicated and foreign, but it describes exactly this simple concept: All documents within an organization should have a specific scope, purpose and intended audience — A bit like LEGO blocks that build upon each other.

Document B can deepen the information presented in Document A by providing more details on a specific part of the process without the need to repeat what was already presented in Document A. Having a clear overv ..

Support the originator by clicking the read the rest link below.