Archive for the 'Checklist' Category

Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan

Monday, March 10th, 2008

Our experience as IT Consultants has shown that Disaster Recovery (DR) plans are often inadequate to effect full recovery of critical business systems. The frequency of testing is also low and these two factors combine to create an unnecessarily high risk for business. This fact, coupled with the increased requirements for reporting on DR in the forthcoming Isle of Man Financial Services Act 2008 has placed disaster recovery back on the agenda for many Isle of Man company directors and business leaders. A recent Institute of Directors survey of SME’s also places DR and Security high on the priority list for action.
In the event of a disaster situation, you need to be certain that you can recover your critical business data and continue to run your business. So in order to help companies improve their Business Continuity planning, I would like to share with you a simple seven step framework for designing, implementing and maintaining your own Disaster Recovery plan.

1. DR Policy

The policy details why you have a plan, who is responsible for it and how is is to be resourced. Legal and Statutory obligations usually feature at key points within your policy statement. It is also important to remember that your policy should encompass people, process and technology.

2. Risk Analysis

Identify failure risks and categorise these by impact - where possible these should be expressed in financial terms. Look out for cascade effects and dependencies between systems - where the failure of one single step has a knock on effect on many others. Performing Risk Analysis (also known as Business Impact Analysis or BIA), allows you to concentrate your resources where they can create the greatest impact.

3. Controls and Preventative Measures

Many simple and cost effective methods can be employed to reduce the risk of failure. Look for single points of failure and balance the cost of implementation against the risk of failure.

4. Recovery Strategy

This is your high level document that should specify Disaster Scenarios and how you will respond to them. Typical scenarios might include: Pandemic Flu, Building Lockout, Server Failure, Power failure. The strategy document sets the targets for the DR team to meet. You must skip the detail at this stage and concentrate on objectives. In Disaster recovery parlance, the most useful here are Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO). You should also consider here how you will communicate with your staff, customers, press and other stakeholders and how you will decide to invoke your DR plan. You should also consider creating a core DR team made up from representatives of each area of the business.

5. Detailed Recovery Planning

For each of the scenarios specified in the Recovery Strategy, a detailed recovery plan is drawn up. The outputs from this step are comprehensive plans for how you will achieve the strategic objectives. All areas of the business need to contribute and show that they have plans in place and that your staff are aware of how these will work in practice. Typical things to consider are data backup, telephone and telecommunications arrangements, office space, insurance. You will need to be able to demonstrate compliance with the legal and statutory requirements of your particular industry sector. All of these arrangements must be documented and lastly and most importantly, be made available off-site. You do not want your recovery plans to be locked in a building you no longer have access to!

6. Test the Plan

Once you have created your DR plan, you must test it. In some industry sectors this is a requirement that must be met annually. If you can arrange for independent testing then do so, as it can be difficult for those closely associated with the creation of the plan to remain objective when testing it. If your business is large enough you can form two DR teams, one to create and one to test. Tests can be desk-based, partial recovery or full recovery.

7. Maintaining the Plan

Change happens! As a result, disaster recovery plans must change too. Because you keep a copy of your disaster recovery plan in multiple locations, you need to make sure each copy remains current. Too often we find that planning for DR is something we do after a new business project is implemented. Embedding DR planning into your project management process will mean that new projects will trigger the requirement to maintain the plan.

If you require any assistance with your own disaster recovery planning and testing, KDR Ebusiness can help. Our experience can help you to meet your statutory requirements and reduce the business risks you face. If you already have an in-house team, we can provide an independent, external audit and test of your existing plan.

Bookmark to:
Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to Del.icio.us Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to digg Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to FURL Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to blinklist Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to My-Tuts Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to reddit Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to Feed Me Links! Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to Technorati Add 'Disaster Recovery Planning and Testing: 7 Steps to a better DR Plan' to Socializer 

The IT Managers Checklist: Part #1

Friday, October 13th, 2006

The role of the IT manager is dependent on several factors, with the top three being organisation size, industry sector, and geographic distribution. The detailed IT Managers checklist for each of these would be widely different, but for the purposes of this article I would like to concentrate on the common threads that should appear in every IT Managers checklist.

As an ex IT manager of a small/medium sized enterprise (<250 staff, finance industry, 3 locations) my own checklist had four items at the top level, and I think that this was a good starting point which helped me to prioritise and concentrate our efforts.

Legal/Statutory
These are the must do things that ensures your organisation stays on the right side of the law. Within the IT world there are an ever increasing number of legal and statutory requirements. A good IT manager should have a working knowledge of them and know how they might affect the company they work for.

Operational/Support
Operational encompasses the scheduled and regular tasks that should be done in order to maintain a stable and available set of IT services. Support deals with services that are not working properly.

Project/Development
Projects are intended to achieve a specific benefit or business objective, and most IT development, coding, infrastructure improvements, etc., would fit within this category.

Strategic
Here I would include IT finance and budgeting. Work on policies and procedures, awareness of emerging technologies. But most importantly the IT manager should understand the business direction and drivers, and determine how IT can assist in the success of the company.

As an IT manager this helped me to keep the big picture in mind. But what about you, and bearing in mind the high level, is there anything else you would add to this checklist?

Later in Part #2 we’ll put a little more flesh on the bones.

Tags: ,

Bookmark to:
Add 'The IT Managers Checklist: Part #1' to Del.icio.us Add 'The IT Managers Checklist: Part #1' to digg Add 'The IT Managers Checklist: Part #1' to FURL Add 'The IT Managers Checklist: Part #1' to blinklist Add 'The IT Managers Checklist: Part #1' to My-Tuts Add 'The IT Managers Checklist: Part #1' to reddit Add 'The IT Managers Checklist: Part #1' to Feed Me Links! Add 'The IT Managers Checklist: Part #1' to Technorati Add 'The IT Managers Checklist: Part #1' to Socializer