Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


06:10 PM
Connect Directly

Rethinking Resilience: Tips for Your Disaster Recovery Plan

As more organizations face disruptions, a defined approach to recovery is imperative so they can successfully recover, experts say.

The worst time to learn your disaster recovery plan is outdated is when a disaster occurs. As more businesses are prompted to turn to recovery plans, many have learned there is room for improvement to create a defined approach to recovery so they can bounce back from incidents.

Between 70% and 75% of organizations activated recovery plans in the last two years, Gartner research vice president Roberta Witty said in a talk during this week's Security and Risk Management Summit. Of the 298 that did IT disaster recovery, 23% report addressing one incident; 22% report two; 16%, three; 7%, four; and 8% report at least five events.

Related Content:

Security Through an Economics Lens: A Guide for CISOs

Special Report: Computing's New Normal, a Dark Reading Perspective

New on The Edge: Think You're Spending Enough on Security?

"With so many organizations having disruptions — up to five events over the last 24 months — having a defined approach for a recovery plan is imperative so you can successfully recover from all types of events," Witty explained.

There are several reasons why existing business recovery plans aren't effective. Many of these plans are outdated, for one, and often organizations lack the situational awareness they need to properly respond to any given security incident.

"Lots of times, you don't have enough information about the actual crisis at hand," she said. "The plans and procedures you've defined don't really align with what's taking place in that moment." Other problems include the development of an enterprisewide plan and neglecting to use automation, without which it's harder for businesses to align, update, and use plans.

Of course, there's no such thing as a generic recovery plan. Each plan has to be specific to the company using it, she added, and a strong plan starts with a strong program and governance structure. This means taking the time to detail each phase of business continuity management: program development and governance, recovery requirements, risk mitigation, recovery plan development, exercises and staff training, and program maintenance and management.

"Failing to document plans appropriately, and at the appropriate level of detail, may lead to a delayed or incomplete recovery," Witty said.

She detailed some key challenges that organizations are likely to face as they build disaster recovery plans. The first is lack of strong support for business continuity management at the executive level. Business and executive teams may not think a crisis will happen or feel overconfident in their ability to handle it. If the company is large and complex, it may not understand the full scope of a plan. "Business units think business continuity is all IT's problem," she added.

The solution here is to define a strategy that details each executive's responsibility across the organization. A crisis or emergency management, for example, may fall to the CEO, president, or legal department; an IT disaster would fall under the purview of the CIO. Third-party contingency processes may fall to procurement.

Another key challenge is not having a recovery plan framework in place — or having a recovery plan that is so complicated or high-level that it's almost unusable, Witty said. The most common types of recovery plans include business continuity plans, IT disaster recovery plans, third-party contingency plans, and crisis management and communications plans. Others include pandemic plans, return-to-workplace plans, or succession management plans.

The amount of plans an organization has largely depends on its footprint: Is it a global business, or does it only have one operating location? Are there multiple business units, or regional distribution of the business? All of these can dictate the kinds of plans that are most relevant.

"Businesses are still not taking recovery seriously," said David Gregory, senior director and analyst in Gartner's risk and security division, in a separate session focused on business continuity management. As more organizations depend on digital infrastructure, the need to adopt an integrated approach will continue to grow.

"Security and risk management leaders will need to look beyond IT failures to ensure there are resilient structures in place," Gregory said. 

Writing Tips for Recovery Plan Development
Witty encouraged businesses to be "prescriptive, not narrative" when writing disaster recovery plans. Include the who, when, and how of the way processes should unfold. Include sections to detail specific scenarios or hazards that people might face should a specific incident take place.

"Don't recreate standard operating procedures," she emphasized. "A recovery plan is not to redo what's already documented." She suggested using graphics whenever possible, as readers can consume content by viewing a graphic faster than they can reading blocks of text. 

When writing out procedures, avoid using data that can easily change. Instead of referring to people by name, write their role instead. In the appendix, list which people hold each position for reference.

While every recovery plan may look different, aspects of the table of contents should look the same. Witty advised including a document management section to detail what the plan is for, a change history, and a glossary of terms. It should also include a reference guide that defines the scope and purpose of plans, and sections for how to use the plan and overview of strategy.

Each plan should have roles and responsibilities defined, along with an overview of procedures, she continued. Five sections are crucial: how to activate the plan, how to respond to the event, how to recover, how to restore and move back to production, and how to deactivate the plan.

It helps to have sections on how the plan will be maintained and how often it will be exercised. Appendices can include additional information such as maps and checklists, role-to-person mapping, and lists of vendors and trusted sources to contact when an incident occurs.

Witty advised creating disaster declaration levels, something that "few organizations do well, and when they do it well, it really makes a difference. What are those thresholds that would make you have to declare a crisis?" Having an outline for what constitutes a crisis will cut down on the guesswork for when it's time to declare an emergency.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Google's new See No Evil policy......
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-18
RIOT-OS 2021.01 before commit 44741ff99f7a71df45420635b238b9c22093647a contains a buffer overflow which could allow attackers to obtain sensitive information.
PUBLISHED: 2021-06-18
SerenityOS contains a buffer overflow in the set_range test in TestBitmap which could allow attackers to obtain sensitive information.
PUBLISHED: 2021-06-18
SerenityOS in test-crypto.cpp contains a stack buffer overflow which could allow attackers to obtain sensitive information.
PUBLISHED: 2021-06-18
SerenityOS before commit 3844e8569689dd476064a0759d704bc64fb3ca2c contains a directory traversal vulnerability in tar/unzip that may lead to command execution or privilege escalation.
PUBLISHED: 2021-06-18
RIOT-OS 2021.01 before commit 85da504d2dc30188b89f44c3276fc5a25b31251f contains a buffer overflow which could allow attackers to obtain sensitive information.