Things, IT firms need to cover in the Disaster plan

Natural disasters are unpredictable,  IT disasters are not an exemption, disasters cause huge loss of lives and assets and its recovery shouldn’t be. In fact, recovery should be planned, foreseen and managed. The following steps will aid you to organize your thoughts, ask the proper questions, and develop the right strategy to build a DR plan that is closely aligned with your business.

  • Conduct an asset inventory

A program to retrieve from a disaster should always begin with a record of all your IT assets. This is important to untangle the complexity of your environment. Start by listing all the assets under IT management, including all servers, storage devices, applications, data, network switches, access points, and network appliances. Then draft where every asset is actually located, which channels it is on, and classify any dependencies.

  • Conduct a risk estimation

Once you have outlined all your IT assets, networks, and their dependencies, go through each and record the internal and external threats to each of those assets. Envision the worst case scenario — and be thorough. These threats could include natural disasters or mundane IT failures.

Next, combine the possibility that the event may occur and the impact it would likely have if that event were to occur. How will it affect business flow if each scenario were to occur? This is also a good time to obtain the aid of your colleagues. Just learn to highlight the fact that ordinary events occur much more commonly than natural disasters. Move the discussion away from earthquakes and hurricanes and more toward the higher possibility that the location will experience a power outage or IT hardware failure.

  • Define the criticality of applications and data

Before you start to build out your IT disaster recovery plan, you must organize your data and applications according to their criticality. Start by conversing to your colleagues and support staff to determine the criticality of each application and data set.

Look for commonalities and group them according to the criticality to your business continuity, the frequency of change, and retention policy. You do not need to apply a separate technique to every single application or dataset that you possess. Organizing your data into classes with related properties will enable you to execute a less complex strategy to recover.

  • Define recovery objectives

Different classes will have different recovery objectives. For example, an e-commerce database may be important to recover and have very competitive objectives because the business just can’t bear to succumb any transactions. On the other hand, Internal system may have less robust recovery objectives and be limited relevant to recover since the data doesn’t alter very frequently and it’s less important to get back online.

Setting recovery objectives without consulting the business line managers are the number one reason for misalignment. It’s necessary that you include them in this process to secure the business can recover properly during a disaster.

Here is a sample list of questions you can ask your business colleagues:

  • What applications and data do your department practice?
  • What is your limit for downtime for each?
  • What is your limit for data loss for each?
  • Are there times when these applications are not being used by employees partners or customers?
  • Would you ever require to recover data that is earlier than 90 days old? How about 6 months old? How about 1 year old?
  • Are there any requirements (internal or external) for the organization to retain the data for a designated period of time?
  • Are there any requirements that preclude us from moving the data from one geographical region to another?

The key here is to know business needs and implement a differentiated level of service availability based on priority. Now that you have that information hand, it needs to be translated into recovery objectives to be included in your disaster plan

Recovery time objective (RTO) — What is the acceptable time any of your data and production systems can be unavailable? This is your recovery time objective. To calculate the RTO for an application, estimate how much income your organization would succumb if the application went down for a given period of time. For instance, how much would you miss if your customer portal went down for an hour? How much cost would be incurred if none of your employees can work because email is down?

Calculating your RTO is necessary for determining the features you require in your data security systems and products. For example, if you have a very huge RTO (say, more than four hours), you will presumably have time to back up from tape, but if you hold a very low RTO, you need to use host-based replication or a disk-based backup with constant data security features.

Recovery point objective (RPO) — What is the tolerable amount of data your business can manage to lose? That is your recovery point objective. If your organization has a high susceptibility for data loss, your recovery point objective (RPO) can be large, from hours to days. If your business can’t bear to lose any data, or very little, your RPO will be seconds.

  • Discover the right tools and techniques

Once you have classified all your IT assets, drafted their dependencies, and assorted them together based on their criticality and restoration objectives, it’s now time to determine what tools and techniques to use.

Just make sure that what you select allows the proper level of protection. Over-protection can cost the company excessive money and begin unnecessary complexity. Under-protection can be fairly bad since it will set your business continuity in danger.

For example, regular backups using traditional (file-based) methods are more than adequate for low-impact data but would be improper for high-impact data and applications. Possibly the most critical part of your backup and disaster recovery plan is offsite protection. This should be practiced despite the type of data backup method you prefer. The method should be commensurate to your recovery objectives. Make assured your data is sent to a location that is far enough away that it is not in the identical geographic location. Typically, this is at least 50 miles away from the primary location.

Finally, automation and streamlining of the recovery process much advanced in data protection. In the event of a disaster, quintessential IT staff may be unavailable. Automation also lessens the risk of human error.

  • Get stakeholder buy-in

Go exceeding the walls of the data center and include essential stakeholders in all your business units (i.e. application owners and business managers). They must be included in the planning phase. And they should concur with you about the company’s priorities and service level agreements (SLAs) your team will provide. Also, discuss with your strategic partners and vendors to make clear you’re obtaining the most obvious of your DR solution or services. Be sure not to repeat that slip and stay in close connection with any businessperson you hire.

  • Document, communicate and test your plan

In a disaster situation, you need a documented approach for how to get back to a working environment. This document should be drafted and available on time for the people who will use it.

Often communicate your DR plan to all people in the organization to avoid single dependency, what happens the only one person in the organization really understands the entire picture, and that one person is unavailable during a disaster. In addition, be sure to file your DR strategy where it can be obtained during a disaster. Ideally, it should be printed and posted in various locations.

There is an old saying, “Practice makes perfect.” that means practice brings perfection in the process. No organization ever prepares to perfection with its disaster plan, but practice will help you detect and correct problems in your plan, as well as enable you to execute it faster and more accurately to reduce loss at the time of incidents. Make sure that everyone who has a part of the role to play must attend the practice sessions.

  • Appraise and renew your plan

A DR plan should be an existing document. It’s very important to constantly evaluate your plan provided for an ever-changing business environment. Limit for downtime and data loss may decrease. Important personnel may terminate their employment. IT might shift to new hardware or operating systems. Your planning needs to reflect the current situation of the organization.

Get more information about Things that IT firms need to cover in the Disaster plan, Click here.