In disaster recovery (DR) and business continuity (BC), an incident response is the step-by-step process of responding...
to data security breaches such as lost laptops and Web application hacks that are listed at the popular Chronology of Data Breaches website. Incorporating incident response plans in your DR/BC plans is essential for keeping critical company data safe and secure.
Incident response plans help minimize business risks, and they're mandatory in today's computing environments. However, incident response is often ignored at many enterprises because they think that it doesn't serve any significant purpose. Rather, their main focus is on recovering from disasters and keeping critical business systems and processes running during a disaster. And even though hack attacks and malicious internal use are forms of disaster in a company, they still end up as an afterthought.
Even with the general lack of incident response adoption, no one can say it's not a visible component of information risk management. Many government and industry regulations have sections and requirements on incident response: HIPAA (section 164.308(6)(i)), GLBA (section 314.4(b)(3)) and PCI DSS (section 12.9). Even the widely accepted ISO/IEC 27002:2005 information security framework has a section dedicated to the subject titled "Information Security Incident Management."
A good incident response plan will outline the who, what, when, where and how to respond to data security breaches. Just like disaster recovery/business continuity plans, incident response procedures provide invaluable guidance when you really need it: in the midst of, or just after a data security breach. Arguably the most important aspect of incident response documentation is the process for determining what constitutes an "incident." It may be an external hack attempt or perhaps a type of insider abuse. Incidents may be technical in nature such as a denial of service attack or a Web application hack, or they can be higher level phishing or social engineering attempts. It's up to you and your IT/security/governance committee to decide what types of data security breaches should fall under the incident response umbrella.
An incident response plan would ideally exist as a standalone document. However, you may want to incorporate it into other contingency procedures you may already have such as your business continuity plan. Regardless, you need to document it and place it wherever it's most easily retrievable. The NIST Computer Security Incident Handling Guide has some great information on creating and formatting incident response procedures.
Also, keep in mind that timing is critical during a data security breach. Within seconds, critical information can be lost, and you need to be ready to respond. So ask yourself, "How long will it take me to respond to a data security breach? Seconds? Minutes?" A great way to see where things stand in your organization is to run test drills such as simulated hack attacks, malware outbreaks and lost mobile devices. You may realize that even though you have a disaster recovery/business continuity plan, your incident response plan may need more work.
Data security incidents can have just as grave an impact on your business as a physical disaster. Incorporating incident response into your DR/BC plan is important to keep you away from disasters and incidents that may harm your company. Anything less is akin to ignoring the realities of today's threats and hoping for the best.
Using a pandemic recovery plan template: A free download and guide
Business continuity plan auditing best practices
Implementing the National Incident Management System and Incident Command System in DR plans
Incident response template for planners