Leave no threat unattended!

Threats to IT systems today come in multiple formatsviruses, hacking attacks, sabotage, power outages, natural disasters, and maybe even a doomsday catastrophe.

The challenge for the helpline, however, doesnt change, no matter what the nature of the threat isit has to keep working in all situations.

Sure, all organisations that value their information assets have a disaster recovery strategy in place and also keep re-examining it on a periodic basis.

Indeed, it has become an essential ongoing exercise in the wake of todays complex threat scenario, to which newer strands are being added with each passing day.

While that is good, its not enough. It is the adoption of some key best practises that will give the IT department the required peace of mind.

Fix the ownership
Today, more and more organisations are looking to increase the involvement of business managers in the development and maintenance of their business continuity plans (BCP). What this means is that business continuity is now increasingly being seen as a line function rather than a staff function.

This also means that it will be a good idea to segregate BCP from disaster recovery, and split them as two separate initiatives, each with its own set of policies and goals.

For disaster recovery, the goal is technical recovery, and the plan is created and managed by developers and engineers. Business continuity on the other hand should aim to achieve business process stability, and it will be more effective if the plan is chalked out by business managers or owners of respective processes. Of course, it goes without saying that the plan should be developed in close coordination with the IT team.

Classify the risks
When evaluating risks and threats, effort should be made to categorise them into different classes. This will help prioritise the assets that need to be protected first. For starters, its always a good idea to tag the risks into five basic categories.

External risk: External risks are those that cannot be associated with a failure within the enterprise. They are very significant in that they are not directly under the control of the organisation that faces the damages. These will include natural disasters and civil unrests.

Facility risk: Facility risks are the ones that affect only local facilities. These typically cover aspects such as electricity outages and physical structural faults.

Data systems risk: These are related to the use of shared infrastructure, such as networks, file servers and software applications that could impact multiple departments. A key objective in analysing these risks is to identify all single points of failure within the data systems architecture.

Departmental risk: Departmental risks pertain to failures within specific departments. These would be events such as a fire within an area where flammable liquids are stored, or a missing door key preventing a specific operation.

Desk-level risk: These comprise all the risks that can potentially limit or stop the day-to-day personal work of an individual employee.

Make it independent
There is a strong likelihood that when disaster strikes, the architect of the disaster recovery plan will not be available. Remember this key assumption before working out a plan. At the IT managers end, care must be taken to ensure that the plan will work with or without the people who developed it.

Also, in a development environment, disaster recovery and application development should be aligned and synchronised.

The IT team must incorporate disaster recovery into the application development processes. For example, the business-continuity database should include a report on application-testing status, so that the IT manager knows when a system was last tested and whether it demands his or her attention to assure its performance in the event of a recovery.

Test the plan
While it is important to review your on paper disaster management and business continuity plan on a regular basis, doing just that is not enough. Strengthen your initiative with disaster simulations that can go a long way to test the preparedness of the disaster management team.

And what you derive out of the results of the test will form a further input to the disaster recovery plan. For example, if you are recovering without third-party services, create an action-item checklist of what worked well and what didnt. And if you are working with a vendor, document what went wrong and use that report to outline your needs from the next simulation exercise.

Zapatillas Running