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
Newest First  |  Oldest First  |  Threaded View
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
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-05-16
The JSON web services in Liferay Portal 7.3.4 and earlier, and Liferay DXP 7.0 before fix pack 97, 7.1 before fix pack 20 and 7.2 before fix pack 10 may provide overly verbose error messages, which allows remote attackers to use the contents of error messages to help launch another, more focused att...
PUBLISHED: 2021-05-16
Denial-of-service (DoS) vulnerability in the Multi-Factor Authentication module in Liferay DXP 7.3 before fix pack 1 allows remote authenticated attackers to prevent any user from authenticating by (1) enabling Time-based One-time password (TOTP) on behalf of the other user or (2) modifying the othe...
PUBLISHED: 2021-05-16
The SimpleCaptcha implementation in Liferay Portal 7.3.4, 7.3.5 and Liferay DXP 7.3 before fix pack 1 does not invalidate CAPTCHA answers after it is used, which allows remote attackers to repeatedly perform actions protected by a CAPTCHA challenge by reusing the same CAPTCHA answer.
PUBLISHED: 2021-05-16
Delta Industrial Automation CNCSoft ScreenEditor Versions 1.01.28 (with ScreenEditor Version 1.01.2) and prior are vulnerable to an out-of-bounds read while processing project files, which may allow an attacker to execute arbitrary code.
PUBLISHED: 2021-05-16
Cross-site scripting (XSS) vulnerability in the Asset module's categories administration page in Liferay Portal 7.3.4 allows remote attackers to inject arbitrary web script or HTML via the site name.