Before Trouble Strikes - Page 2

 By Elizabeth Ferrarini
Page 2 of 3   |  Back to Page 1
Print Article

Conduct Business Impact Analysis
The disaster recovery planning team should perform this step to identify which business departments, functions, or systems are most vulnerable to potential threats, what are the potential types of threat, and what effect would each identified potential threat have on each of the vulnerable areas within the organization.

  1. Identify functions, processes, and systems.
  2. Interview information systems support personnel.
  3. Interview business unit personnel.
  4. Analyze results to determine critical systems, applications, and business processes.
  5. Prepare impact analysis on interruption on critical systems.

Conduct Risk Assessment
The disaster recovery planning team should work with the organization's technical and security person to determine the probability of each functional business units' critical systems becoming severely disrupted and to document the amount of acceptable risk the business unit can tolerate. For each critical system, provide the following information:

  1. Review physical security, i.e. secure office, building access off hours, etc.
  2. Review backup systems and data security.
  3. Review policies on personnel termination and transfer.
  4. Identify systems supporting mission critical functions.
  5. Identify vulnerabilities, such as physical attacks, or acts of God, such as floods.
  6. Assess probability of system failure or disruption.
  7. Prepare risk and security analysis.

Develop Strategic Outline for Recovery
The steps outlined here provide all of the components necessary to perform a recovery. These steps will help pull together information about the operations of all systems, especially those owned or managed by non-technical managers with help from technical support personnel. Steps one through four mainly apply to functional business units that manage technology systems to process critical functions. The disaster planning recovery team and the functional business unit may wish to appoint other appropriate individuals to perform subsequent tasks.

  1. Assemble groups as appropriate for the following:
    • Hardware and operating systems
    • Communications
    • Applications
    • Facilities
    • Other critical functions and business processes as identified in
    • the Business Impact Analysis step.
  2. For each system/process above quantify the following processing requirements.
    • Light, normal, and heavy processing days
    • Transaction volumes
    • Dollar volume, if any
    • Estimated process time
    • Allowable delays (days, hours, minutes, etc.)
  3. Detail all the steps in your workflow for each critical business functions. (For example, for payroll processing include each step that must be complete and the order in which to complete them.
  4. Identify systems and applications.
    • Component name and technical identification if any
    • Type (online, batch process, script)
    • Frequency
    • Run time
    • Allowable delay (days, hours, minutes, etc.)
  5. Identify all vital records.
    • Name and description
    • Type (backup, original, master, history)
    • Where are they stored?
    • Source of item or record
    • Can the record be easily replaced by another source?
    • Backup and backup generation frequency
    • Number of backup generations available onsite and off-site
    • Location of backups
    • Media key, retention period, rotation cycle
    • Who is authorized to retrieve the backups?
  6. Identify if a severe disruption occurred what would be the minimum requirements or replacement of the critical function during the disruption.
    • Type (server hardware, software, research materials, etc.
    • Item name and description
    • Quantity required
    • Location of inventory, alternative, or off-site storage
    • Vendor/supplier
  7. Identify if alternative methods of process either exist or could be developed, quantifying on processing (include manual processes).
  8. Identify person(s) who support the system or the application.
  9. Identify primary person to contact if system or application cannot function as normal.
  10. Identify secondary person to contract if system or application cannot function as normal.
  11. Identify all vendors associated with the system or application.
  12. Document business unit strategy during recovery (conceptually how will the unit function?).
  13. Quantify resources required for recovery by time frame.
  14. Develop and document recovery strategy, including priorities for recovering system/function components, and recovery schedule.
This article was originally published on Jul 12, 2001
Get the Latest Scoop with Networking Update Newsletter