| No disaster recovery (DR) plan can be truly said | | | | important role with greater frequency of testing |
| to be finished until it has been tested, if not in | | | | and more imaginative consideration of the impact |
| real-life, then in the most stringent assessment | | | | of disaster upon the network infrastructure; |
| and testing regime that can be mounted. The | | | | · Standard of Documentation - well |
| stakes are high because your business is at risk. | | | | documented business continuity plans represent |
| A common misconception is also to implement a | | | | the experience of those responsible and the |
| DR plan and then forget about it. Your business | | | | seriousness with which a business tackles the |
| changes to meet the demands of the ever | | | | issue. Where a company is simply going through |
| changing business world in which it operates, and | | | | the motions, to meet regulatory requirements for |
| the same is true for any contingencies you put in | | | | instance, then this should be a warning flag that |
| place to cope with a disaster. A DR plan must be | | | | the plan needs to be readdressed and |
| continuously assessed and monitored in the light | | | | reconsidered; |
| of current known threats and accumulated | | | | · Change Management Implications - has a |
| experience of those responsible for it. | | | | business considered how their business continuity |
| Here are some of the areas to look at and focus | | | | plan integrates with their change management? |
| upon: | | | | When a change is considered or implemented this |
| · Scope - usually a DR plan simply looks | | | | should automatically be triggered to consider the |
| at the mission-critical aspects of a network | | | | impact of the implemented change in the context |
| infrastructure and their recovery. As the plan | | | | of the DR plan so it will continue to meet its own |
| matures, further assets will come under its scope | | | | objectives; |
| because of advances in business continuity | | | | · Systems Design Implications - new |
| techniques and solutions, but also because the | | | | systems are not usually designed with business |
| business comes to rely on more and more IT | | | | continuity in mind, indeed DR plans are usually |
| services which qualifies them as being termed, | | | | implemented after a system has been put in |
| "mission critical"; | | | | place - they are an afterthought. It makes sense |
| · Top-Down Support - senior | | | | to integrate business continuity planning with |
| management play a vital role in the effectiveness | | | | systems design so the DR plan which emerges is |
| of any business continuity plan because without | | | | optimized for the business; and |
| their support the plan itself is unlikely to move | | | | · Responsibility - company awareness of |
| beyond the initial remit of what was conceived as | | | | the DR plan is generall a "good thing", however |
| critical network parts which needed to be | | | | this also leads to complacency in management |
| protected - in other words, the DR plan will | | | | who tend to think someone else has "got the ball". |
| stagnate and become obsolete; | | | | Only when the DR plan needs to be activated will |
| · Testing and Assessment - business | | | | shortcomings emerge, so it is essential that |
| continuity plans are usually typified by having | | | | responsibility for the business continuity and DR |
| restricted testing with some partial storage | | | | plan is explicitly assigned to an executive or |
| replication in their infancy. As the plan matures | | | | executive board. |
| and develops, testing assumes a much more | | | | |