The Importance of Security and Disaster Recovery Plans

September 8, 2017 Jana Langhorne

Having a solid security plan is extremely important to build an effective information management program. The security plan should also include a separate disaster recovery plan for the unfortunate event of an incident. I recently sat down with Mac McMillan, Chief Strategy Officer and President of CynergisTek, to discuss the differences between having a security plan and having a disaster recovery plan, as well as the current state of security.

1. What are the benefits of maintaining separate security and disaster recovery plans?

The security plan, which is much broader by definition, should also encompass contingency planning which is fairly specific by definition as one of its elements. The security plan provides the overarching structure for the direction of the data protection program, while recovery plans address very specifically the steps the organization will follow to reconstitute assets after an incident. Operationally, you want the disaster recovery plans to be a separate component that is readily available to response teams. When in the midst of an incident, the last thing you want the response team to have do is dig through a lot of unnecessary documentation to get to the plans they need.

2. What are the risks associated with creating a single, all-in-one recovery plan?

Contingency planning is broken down into several key components; business impact analysis, continuity planning, recovery planning and back up planning. The overarching plan can and should be in one document to provide cohesiveness between the parts of the plan. However, each individual component may be broken out to facilitate ease of use in time of crisis, updates as needed when elements of the enterprise system environment change, etc. You want the plans (documentation) to be as specific as needed to facilitate rapid action and consistency.

3. In what basic ways do security and disaster recovery plans differ?

Security plans provide guidance for the day to day management of the program and focus on the proactive aspects of risk avoidance.  Think of it as the plan before the storm.  Disaster recovery plans begin when the storm happens and are reactive in nature with a focus on mitigating the affects of the incident and a very systematic and hopefully organized approach to recovery.  A security plan for instance will have guidance on vulnerability management to include applying patches to systems.  The disaster recovery plan will want to know where the latest image is of the system to be recovered or what the most current patch level was just prior to the incident.

4. Do security recovery plans need to be updated more frequently than disaster recovery strategies?

Individual system or application recovery plans will need to be updated more frequently based on changes to the systems themselves, while the disaster recovery strategy may only need revising when there is major change in the enterprise. For instance, when an application is updated or replaced, the recovery plan for that particular asset will need updating. The disaster recovery plan may not need updating, as the system may not have a change in priority or have created any new interdependencies.

5. How does security and disaster recovery plan testing differ?

A security plan may have many different levels of audit and testing that are carried out as routine practices, while disaster recovery plans are tested very specifically around the processes described by them. For example testing associated with the security plan could include vulnerability scans, wireless testing, password or access control audits, etc. Tests that are performed either on a regular schedule or some other periodicity to either maintain something within prescribed guidelines, reassess risks from time to time, or assess whether controls are still effective. Disaster recovery testing will target those things critical to recovery. Such as back-ups, call procedures, incident response plans, down time procedures, communications plans, etc. and most testing of disaster recovery plans is usually accomplished through table tops, actual exercises, or drills.

6. Should security and disaster recovery plans be supervised by the same teams?

Often they are supervised by the same person or position, but the difference is that disaster recovery has a definite team structure with roles. This is important so the one supervising is usually overseeing the process and ensuring all the right people are involved.

7. Are security and disaster recovery plans more likely to diverge or converge over the next several years?

They are already converging as disaster recovery becomes more critical as threats escalate and become more disruptive and keeping the business operating is a business imperative.

8. How can security and disaster recovery plans be designed to complement each other?

The best way to make sure these plans complement one another is by taking a lifecycle approach when considering the protection of the asset and thinking about failure at every juncture and what it will take to avoid that event or recover should it happen. All too often, we acquire systems, or make changes to the network, or implement applications without considering all of the potential ways that they could be disrupted.

CynergisTek encourages you to review your security program plans and your disaster recovery plans if they have not been reviewed in a while.

Previous Article
Groundhog Day: The Cyclical Nature of InfoSec & How We Can Break the Cycle
Groundhog Day: The Cyclical Nature of InfoSec & How We Can Break the Cycle

In the classic movie Groundhog Day, the main character played by Bill Murray finds himself trapped reliving...

Next Article
What Does a Cybersecurity Workforce Look Like?
What Does a Cybersecurity Workforce Look Like?

There is consensus agreement that threats that exploit vulnerabilities in the health care cyberinfrastructu...


Subscribe to Cyber Bulletins with the Latest News, Tips and More!

First Name
Last Name
Join Our Mailing List
Thank you!
Error - something went wrong!