Disaster Recovery Incident Response Business Continuity

In a world getting less predictable every week, good business leaders proactively prepare for cyber incidents with plans that anticipate and minimize disruptions. But as you start looking ahead, it's easy to get confused about the differences between incident response plans, disaster recovery plans and business continuity plans. In this post, we'll explain how the plans all weave together into a holistic strategy to protect your business.

Incident Response Plan

The IR plan is the overarching document that gives your team clear guidance on exactly what to do during incidents, data breaches, and other pressure-packed situations when it's easy to get overwhelmed. If you realize you may be facing a cybersecurity incident, the IR plan will help direct your actions. Every good cybersecurity program puts a high priority on writing and regularly reviewing an IR plan. In many cases, you may be required to have one by industry regulators, your cyber insurance company, key customers who want assurance that you can handle incidents, etc.

Your IR plan will describe your specific:

• Definition of an incident – A clear checklist helps your team recognize situations serious enough to set the IR plan in motion. The plan also should include criteria for identifying the next stage: an actual disaster that triggers the disaster recovery/business continuity (DR/BC) plan.
• IR team structure with each person's responsibilities – This list ensures you have the right voices in the room. It's easy, for example, to include a lot of IT people and forget to include reps from HR, legal, PR, etc. Be sure to include an executive who can make things happen in a pinch. For each person, clearly describe what they'll do during an incident.
• Procedure for reporting incidents – The plan works only if the right people learn about the incident in a timely manner. Clearly explain how team members should report suspected incidents through the right chain of communication.
• Guidelines for talking to outside parties – When do you tell your customers what happened? Who is allowed to talk to the media if they call? Your plan should anticipate those scenarios and describe what to do.
• Structure for summarizing lessons learned – Create a method for debriefing the incident, clearly stating what happened and making adjustments as required.

Disaster Recovery

Note that many organizations combine the DR and BC plans into a single document that outlines the processes involved for declaring a disaster, the formulation of the Response Team Members, the processes necessary for a secure recovery, and finally the steps necessary to maintain the continuity of business operations. We'll explain the differences in the documents here, but rather than fixating on rigid definitions, just make sure you have thorough plans in place.

The DR plan usually centers specifically on data and technology operations with processes for recovering information systems at an alternate facility in response to a major hardware or software failure or destruction of facilities. The DR plan explains, for example, how you can restore lost data, whether that means restoring a single system or an entire data center.

The DR plan will include details such as recovery time objectives (RTOs) and recovery point objectives (RPOs). These define, respectively, how long you can function without a service and how current the data must be when you restore it. For example, RPOs may tell you that restoring copies of training materials from 48 hours ago isn't a problem. But if your business runs on current stock market trading data, the RPO will show that you need data to be current within a few minutes.

Business Continuity Plan

The BC plan describes how you'll maintain operations during and after a significant disruption or an incident. The BC plan should include a triage process for restoring the most essential operations first, such as filling customer orders, making payroll, supporting business partners, etc.

Your BC plan will explain how you can maintain operations in situations such as:

• Encryption of your data by hackers
• Loss of power to your facility
• Failure of a supplier to deliver key materials
• Natural disasters

The BC plan rests on the foundations of an overall information technology risk assessment and a business impact analysis (BIA). The BIA specifically identifies potential operational implications of various scenarios. What happens to your business if, for example, you lose access to a certain database or cloud-based software? How long could you withstand such an outage without major damage to your business? In a BIA, you'll seek to put an actual financial cost on various interruptions so that you can make informed investments in prevention and mitigation strategies described in your BC plan.

Essentials for Every Plan

For all three of the plans described in this post, be sure to include these key elements:

• A designated point of contact (POC) and a leader charged with heading up the effort in a specific area. Many compliance frameworks and private contracts require you to name your POC.
• A schedule for updating the plan. Many companies are sitting on plans that have never been revised to reflect a remote workforce, reliance on cloud-based services, etc. Commit to an annual review of the plan and update it to reflect the realities of your operations.
• A schedule for testing the plan. At the simplest level, you should do at least annual tabletop exercises. But you may determine that your situation requires more extensive testing.

For help assessing your specific business risks and making a plan to mitigate them, contact Pratum today.

williamsancestright.blogspot.com

Source: https://pratum.com/blog/540-incident-response-vs-disaster-recovery-vs-business-continuity-what-s-the-difference

Share this post