DRJ's Spring 2019

Conference & Exhibit

Attend The #1 BC/DR Event!

Winter Journal

Volume 31, Issue 4

Full Contents Now Available!

The increase in client/server computing and distributed systems is causing an explosion in LAN disk capacity. Growing companies typically add 30 to 50% more storage to their networks each year, and newer image-based applications will accelerate this trend.

The cost of storing magnetic data is gaining the network limelight, as is the potential cost of lost data. Organizations without a backup and recovery plan for what may be their most precious asset are susceptible to the ravages of disaster, both natural and man made. Major catastrophes over the past few years like Hurricane Andrew, the Midwest Flood of ‘93, Los Angeles earthquake, and World Trade Center bombing have been front-page reminders that valuable information should be protected.

Concern is usually generated at the highest level of the corporation. The corporate officers of public companies could be held liable if their negligence resulted in data lose that affected profits.

Few sizeable companies are without some kind of data backup and recovery plan. However, there are plans and there are plans. At the weak end of the planning spectrum is the company whose management simply feels that a pinch on staff resources precludes developing and implementing a full-blown program. As a result, this type of company may issue a policy that employees must perform regular backups. But without documentation and accountability, this plan doesn’t have much chance of saving the corporate jewels. The sad fact is that failure of this plan will not be identified until significant data loss occurs.

Unfortunately, this “independent” approach also increases the workload of every employee who is responsible for their own backup. And without an administrator to control the process or be responsible for an ongoing strategy, the backup process is often at risk and backup media is not protected. An employee’s idea of safeguarding backup media could be storage in the trunk of a car or in a closet at home, where it is subject to many other kinds of all-too-familiar disaster.

In the middle of the plan continuum is management that directs a committee comprised of various departments to devise a plan. Documented procedures are essential. The people who devise the plan may not be present when the recovery portion is executed.

Documentation doesn’t guarantee data recovery. Most solutions today entail data backup on site and most are not as automatic as they should be. When deciding on a location for housing data to protect for recovery, companies should not forget that disaster can strike anywhere, including data centers. That’s why a hotsite should be considered. If a hotsite is not a viable alternative, an onsite storage vault should be as secure as possible.

Companies at the strong end of the planning spectrum usually have a network backup and recovery plan with centralized backup ownership and administration. In the past, companies thought that the volumes of backup tapes they created would preserve their data. They learned too late that those piles of tapes couldn’t be read. Therefore, it’s a good idea to verify that tapes are readable. Beyond readability, restoration is the most critical part of the plan. The only way to insure that recovery will work when needed is to test the process.

Tape verifications is one aspect of the “fire drill” approach. In any procedure, practice is essential for insuring that the documented process does what it’s supposed to do and employees have been trained properly. There are various degrees of fire drills, some with warning and some without. But the organization must build its expertise in executing the network backup and recovery plan through practice.

Some organizations are looking for ways to simplify and improve control of network backup and recovery. They want to centralize both planning and administration but support distributed backup using a variety of different backup strategies, systems and media in different parts of the organization. A centralized body develops standards and implements them across the entire organization. A small centralized staff can cost-effectively manage the network backup requirement and restrict the number of qualified products on the market today.

Although standardizing a level of service may simplify initial planning and documentation, a uniform minimum requirement does not address diverse departmental and workgroup needs. A system that can be tailored to different departments within the organization best serves its diverse user.

Custom handling of applications on the client end and backup data on the server end are two areas where versatility of service are important. The concept that a system should offer the flexibility to handle data on PCs within one department differently from PCs in other departments may be expanded to vary data backup from application to application on PCs. A database application may need to be either shut down or placed in a special state prior to backup of the database file. After backup is complete, the application must be restarted. The process should be automated along with the actual backup.

On the server side, it is advantageous for the system to offer customized handling of data backup files. This would allow mounting and dismounting of special media for specific departments or projects.

Consideration should also be given to the amount of flexibility in how the system backs up data, including full and incremental options, when and how frequently it does so, what data may be selected for backup, and options regarding storage media, tape rotation, and storage locations.

A single enterprise network with distributed subnet-networks is likely to include a variety of hardware platforms: VAXs and midrange computers in manufacturing, OS/2 and DOS in administration, Macs and UNIX workstations for various user groups. Add a variety of different departments with varying functions, procedures, and of course backup requirements, and you can begin to see why companies are overwhelmed by the ubiquitous task of developing a backup and recovery plan.

The determination of where to store backup data is a major issue impacted by the physical nature of the organization. Remote locations with lots of data to backup could make the process quite tedious and time consuming if transmitted over a WAN to a centralized managed backup program is an alternative that would eliminate the need for a resource at the remote office to oversee the process, and eliminate the need to move backup data over the WAN. This alternative may come in handy when today’s plan falls short in six months as backup data volume exceeds capacity.

The experts point to a few key criteria that a backup and recovery solution should meet. First of all, it must be an automated, multi-vendor, multi-protocol network backup and recovery solution in order to support a variety of operating systems and platforms (including proprietary and UNIX) that comprise current client systems and adapt to the computing environment as it changes. These factors eliminate quite a few solutions.

Automation is crucial for optimal reliability and efficiency. Automated synthesized backup is the initial backup procedure which entails a complete image copy of all data in the organization. After the original image copy is complete, the system is programmed to automatically produce backup tapes of only the changes made to the imaged data. The original image copy is merged with backups of all changed data sets on a regular basis to recreate an image of the current environment.

The process is likely to take several days or weeks, so the system should offer backup that is interruptible and restartable in order to accommodate daily use of the network. The trade-off to this process is its inability to restore data at any given point in time. For instance, engineering could not restore a CAD drawing to its status as of a particular day to eliminate an error and subsequent unusable data. The drawing as it appeared that day would have to be recreated from scratch.

Another issue for consideration is that network transmission for backup uses alot of bandwidth. An intelligent product can implement more efficient movement using compression. A caution: compression algorithms that run on an average server PC lengthen the backup process by adding compression time to transmission time. However, compression does work if the computers performing the compression are powerful.

Although the requirement may sound trite, ease of use for both users restoring data and for network backup and recovery administrators is imperative. The system cannot live by a point-and-click graphical interface alone. The system must be easy to instal, administer and monitor through comprehensive reporting. It must define concrete parameters--the who, what, where, when and how--of data handling and adapt easily to a wide range of disaster recovery procedures.

Karen Winner is a consultant for Winners Marketing Communications in Minneapolis, Minn.

The allure of client/server architecture is very strong for those who want to downsize from a mainframe environment. It promises, among other things, local ownership of local data and distributed processing. Unfortunately, the client/server model introduces complexities in data administration and protection.

Mission critical data must be protected, whether it is stored locally or centrally. Unlike the mainframe environment with its centralized operations staff, sophisticated tools and standardized procedures, client/server applications reside in an open, often fluid, environment. The very aspects that make it so attractive (heterogeneous environments, smaller IS staff, distributed computers) can make administering and securing data a nightmare.

Even in a centralized IS environment, client/server databases typically lack the sophisticated backup and recovery tools taken for granted on the mainframe system. Wherever backups are inadequate or not consistently performed, valuable data is at risk. In the case of Oracle, a leading relational database management system (RDBMS), existing backup and recovery procedures are complex to learn, deploy and maintain, leaving core applications vulnerable to failures or long outages.

With the growing number of client/server applications maturing and supporting vital corporate functions, ever increasing amounts of critical data is being put at risk.

Oracle Backup/Recovery Today

Current backup and recovery methods for production Oracle databases not only take a great deal of time, they also demand a high level of expertise from database administrators (DBAs).

To carry out successful backup and recovery using traditional methods, DBAs first need a comprehensive understanding of the structure of the database and the relationships between the files. They need to write, or have written, robust scripts for backing up all of the necessary database components. They need to maintain these scripts consistently as database files are added or changed.

Once the system is in place and running, DBAs need to perform and carefully track database backups and exports, which requires a good system for identifying and locating the actual backup tapes and files. In practice, this tracking system may be maintained by the DBA, the system administrator (SA) or some combination of the two.

Database recovery relies even more heavily on the DBA not only correctly retrieving the files, but understanding the nature of the failure, identifying the correct files to retrieve and performing the appropriate actions to recover the database. The heavy reliance on the DBA's presence and expertise leaves some institutions vulnerable to failure because they cannot reach the right person, or because they are experiencing turnover in the DBA group.

The Risks

The risks to data can be classified as five key areas in the development and implementation of a backup/recovery strategy:

  • establishing the backup procedure
  • maintaining the backup procedure
  • recovering data
  • adjusting for growth
  • cross-system interaction

The three mainstays of a comprehensive backup and recovery plan are:

  • physical backups (usually a combination of cold and hot backups)
  • archivelog management
  • regular database exports

If one of these is missing, it may not be possible to recover from some failures. The human component is of such importance here that obtaining the services of a well qualified DBA is often critical. However, as the range of Oracle applications continues to expand, good DBAs are harder to find.

Organizations with experienced DBAs are always at risk of losing them; turnover rates are high. Isolated departments in organizations that are beginning to hold mission-critical data may not have the expertise locally to set up or adhere to standard backup procedures - they may not even recognize that they need to do this.

Most Oracle DBAs have heard the story of the DBA who added a data file but forgot to modify the backup script and found after a failure that there were no backups. It may just be a DBA legend, but it does highlight a basic flaw in the process - ongoing vigilance is required to keep the backups up to date.

Also, it is often the case that the people who write the backup scripts are not involved in the maintenance process; they may even work for a different company. As one manager at a major financial institution told us, "We're okay as long as those consultants who set it up are still around."

Setting up the backup procedure is often the task of the consultants or developers who build the application and who move on to other projects, departments or companies when the project is complete.

If the scripts themselves are not easily maintainable, the DBA responsible for the database may ultimately have to create a new backup procedure from scratch.

Recovering Data

Like the backup process, Oracle database recovery requires a detailed understanding of the nature of the failure, exact information about what data is required to be recovered and a comprehensive understanding of the Oracle database structure and recovery processes.The inevitability of failure occurring at a supremely inconvenient time simply adds to the pressure under which DBAs must work.

It is possible to have all the right pieces available for a recovery, and still not put them together correctly for a consistent database recovery.

In some sites, a system administrator is responsible for writing to tape the actual files that comprise the database, and for recovering them from tape. In this case, the DBA cannot perform a recovery alone.

It now depends not only on the DBA's expertise and time, but also the system administrator's expedience in finding and recovering specific files. Inefficient communication between the two will delay a complete recovery and may result in a key application being unavailable for a prolonged period.

Adjusting for Growth

Even with a devoted and knowledgeable DBA, flawless scripts, fast tape drives and happy users, there is no assurance that a current backup system will continue to work as the database grows.A backup system that's fine for a 2G database may be unacceptable for one of 20G and impossible for one of 200G.

Many DBAs anticipate significant growth in both database size and usage requirements for the applications they maintain. Very few have determined how they will work with those growth requirements.

Most are optimistically counting on the database vendors supplying something before the problem becomes critical.


Database vendors often provide no tools or guidance on backup and recovery issues, and any administrative tools they will supply are for their own databases. Sites with more than one vendor's database in-house must either maintain separate, different procedures for each type of database, or look for an integrated solution that uses common procedures for all mission-critical databases.

The problems, therefore, are manifold. They occur with staffing, with the supply of tools, and the complexities of creating an efficient backup system and of recovering from a failure.

The likelihood that databases will continue to increase in size simply compounds the problems outlined above. There is clearly a requirement for tools that are specifically designed to manage large databases, though it is often beyond the scope of database vendors to develop such software.

The future lies in backup and recovery tools that look at the complete scope of backup and recovery tasks that DBAs face in the Oracle environment, including maintaining backup configurations and performing complex recoveries. These tools should address all five areas described earlier in which problems occur to be truly successful solutions for complex client/server environments.

Anne Janzer is a Product Marketing Manager for DataTools, Inc.

Many organizations seeking to improve their business recovery programs have opted to utilize software to assist them in plan development and maintenance.

These organizations seek out software suppliers offering tools that assist in the management of the overall recovery program. Each organization establishes specific criteria the resumption planning software tool must incorporate to meet its needs. Most organizations rank ease of use as a high priority on their list of criteria.

One of the most compelling reasons one software package is selected over competing products is the ease-of-use issue. This is true because many people with varying skill levels throughout the organization must use the planning tool.

As a vendor of software, we are confronted with the ease-of-use issue every time we talk with people involved in selecting software for their organization. When software purchasers make their final decision, we often hear, “we selected your product because for us it was the easiest to use,” or “we selected their product because it looked easier to use”.

Nonetheless, ease of use is a very broad term, encompassing a variety of more specific definitions. If you ask several people to describe ease of use you will get different answers depending on each person’s specific area of concern. What then does ease of use really mean? How does ease of use rank in the selection process, and more importantly, how should it rank?

EASE OF USE: An Explanation

Employing an easy-to-use software tool does not require that the user possess a great deal of specialized knowledge nor training to produce the end product. That is to say, ease of use is a characteristic attributable to the process of using a software tool. The tool is graded on the simplicity of its use. Therefore, ease of use is a process issue.

Ease of use is not an end product issue. The end product produced by the software tool cannot be attributed the characteristic, ease of use. A product issue focuses on the end result, the plan, not how the plan was processed.

For example, suppose I wanted to become a world class golfer. First, I would have to practice my golf game on some challenging courses. The process is practicing and playing golf, the product is becoming a better golfer.
This analogy holds true with software. The purpose of recovery planning software is to complete and maintain an effective business recovery plan. This plan is the product. How the product is produced is the process.

Depending on the software, the process of producing a business resumption plan entails varying degrees of difficulty. Regardless of how easy the process (or software) is, the end product (or the business resumption plan) still must be measured on its own merits. Therefore, when evaluating recovery planning software, ease of use should refer only to the process of producing the plan, it should not refer to the end product, the plan itself, or the quality of that plan.

With regard to business resumption planning tools, this process/product differentiation becomes critical. In order to resolve this issue, an organization must ask an important question: Are we using a planning tool to get some information into the tool, or are we using it to produce a high quality plan? More specifically: Are we looking for the easiest to use software, or are we looking for a tool that allows us to meet our planning objectives in the most efficient manner? While the answer to these fundamental questions may seem self-evident, it is easy to overlook during the initial phases of the software selection process.

In keeping with the golfing analogy, I have several options open to me. The first is to jump in my car and drive to a local public golf course. The other options open to me all involve some travel, planning efforts, and cost. For example, I could make travel arrangements to fly to northern California and play Pebble Beach. Both of these options meet the basic definition of playing some golf.

On the surface, the local golf course option seems to have the edge in the ease-of-use category. Obviously hopping in my car and driving a few miles is easier than making travel arrangements and taking the time and incurring the expense to travel to play Pebble Beach. Remember, however, my goal was not to just play golf, but to play the most challenging courses to truly improve my game. In order to achieve improvement on my local municipal course, I would have to get out bulldozers and cranes and create a course that would challenge me like Pebble Beach. Clearly, what appears to be the easiest option when judging only the process, becomes unacceptable if it does not lead to the desired end product.

This illustration applies to the ease-of-use issue when selecting a business resumption planning tool. If the end product, namely the plan itself, does not meet your business resumption objectives, the process used to produce the product becomes an unacceptable alternative, no matter how easy it is to use.

Through the years, a number of planning tools have appeared on the market to meet a simplified definition of easy to use. These products are easy to use because the process they follow involves filling in some blanks and printing out a pre-formatted plan. By any definition, this “cookie-cutter” or “one size fits all” approach is easy to use.

By increasing the perceived ease of use in a planning tool, the user’s flexibility and control over the end product is decreased. In other words, when a user is denied options, a product will appear easier to use.

If you do not have the choice of customizing reports and screens, or recording information specific to your business or industry, the planning process seems easy. However, when the user’s flexibility and control over the process is limited, it is prudent to examine what effects this will have on the end product.

Realizing your goal means producing complete, accurate, maintainable, and viable business resumption plans.

EASE OF USE:A Definition

A truly easy-to-use business planning tool allows you to:
1) efficiently enter all of your vital information
2) easily maintain that data as your business changes
3) quickly extract the vital information in a usable format
4) produce a complete plan that meets your business’s unique requirements.

Efficiently Enter Data

A software tool built on a relational database platform, allowing any user to take advantage of the database structure through all phases of the planning process, from data entry to reporting to plan production, is desirable.
The planning tool should have a database which sets up relationships between different bits of information. In other words, data entry in a relational database entails simply entering a piece of information once, and then relating it to all other appropriate pieces of information. This concept reduces data entry time and virtually eliminates data inconsistency.

Easily Maintain Your Data As Your Business Changes

If plan maintenance becomes difficult, it will be ignored. If maintenance is ignored, the information will quickly become obsolete. Obsolete information leads to an ineffective plan. An ineffective plan is equivalent to no plan at all.

When any portion of your plan changes, be it a phone number, serial number, or action item, the change should only need to be made once and then be automatically propagated through your entire plan.

Quickly Extract Vital information

Comprehensive reporting capabilities is a crucial element of a truly easy-to-use tool. If it is difficult to get the information out of the tool, especially in a meaningful format, the tool is not easy to use. Business resumption planning must include many areas of a business; therefore, it is critical to extract the information in multiple formats. It is not uncommon to need information regarding personnel, business functions, inventory requirements, and recovery steps on a single report.

Produce A Complete Plan That Meets Your Unique Requirements

The real purpose of a resumption planning tool is to create a plan that meets your needs. A tool that is perceived to be easy to use becomes an unacceptable option if the output does not meet your needs.

Revisiting the golf analogy, I can play golf on my local course everyday and technically meet my objective of improving my golf game. However, if I want to meet the true purpose of my goal to become a world class golfer, I will have to play the best courses like Pebble Beach.

So it is with business resumption planning. If you want to use any tool because it is perceived as easy to use, you can technically meet your goal of doing disaster recovery planning. But if you want to meet the true purpose of the planning project, you will use a planning tool that helps you build complete, effective plans, in the most efficient, functional manner possible.

Functionality and efficiency are the true determinants of an easy-to-use planning tool.

Michael Gomoll is a Marketing Executive with CHI/COR Information Management, a disaster recovery software and consulting firm in Chicago. Prior to joining CHI/COR, he was a marketing representative with IBM. He holds an undergraduate degree from the University of Wisconsin and an MBA from DePaul University.

This article adapted from Vol. 5 #4.

This is the first of a two-part series that describes the process for selecting a PC-based disaster recovery planning system and the important features, functions and capabilities of the software.

Most organizations depend heavily on technology and automated systems, and their disruption for even a few days could cause severe financial loss and threaten survival. The continued operations of an organization depend on management’s awareness of potential disasters, their ability to develop a plan to minimize disruptions of critical functions, and the capability to recover operations expediently and successfully.

Organizations have experienced various degrees of success in developing disaster recovery plans. A particular problem is that the individuals assigned to the project may not have the experience and most importantly, the time to dedicate to such an effort. A rule of thumb is that the planning process requires approximately a one-person year to complete. Using a good PC-based Disaster Recovery Planning system can reduce the time and effort in the planning and development process to only a few months. Other benefits include:

  • A systematic approach to the planning process
  • Predesigned methodologies
  • An effective method for maintenance
  • A proven technique

There are several PC-based products on the market; however, a careful selection and implementation process is necessary to achieve the benefits described above. Major areas to consider include:

  • General functions
  • Disaster recovery plan development
  • Database management
  • Testing
  • Security

This article explains the various features, functions and capabilities of PC-based software

One of the most important aspects of Business Continuity Planning is designing & maintaining the plan document. This seemingly simple task is not only important, but all too often it is very time consuming. By selecting the right product before you start designing your plan, you can save yourself a lot of time and headaches. The biggest confusion when evaluating software tools is that they all seem to do the same thing, or that one product seems to be just as good as another. This checklist will help you identify key areas for consideration when evaluating Business Continuity Planning software.


1. Can unit plans be rolled-up into a master plan in an orderly structure? (i.e., there’s a fire in the building and you need to relocate affected areas...can you get summations of equipment, chairs, desks, PCs, phones, etc., for the affected areas only?)
2. Can unit plans be individually printed during a test or disruption? (i.e., there’s a telecommunications event that disrupts your Customer Service department in various states...can only your Customer Service DRP be printed, regardless of location?)
3. Will all subordinate plans be included in a single plan execution? (i.e., the building is inaccessible; you execute the “building plan” and get all “subordinate” plans, instead of being forced to execute each plan individually.)
4. Is the software database driven? (i.e., plan development is accomplished primarily through data entry screens, and data is stored in a database, instead of word processor.)


5. Can the product be populated with data resident on another system? (i.e., you want to enter employees from the HR system, and your vendors from Purchasing system; is there an import capability so you don’t have to perform data entry?)
6. Will imported data be reflected in the product’s audit-history sub-system?
7. Does system prevent accidental import duplication?
8. Can the import function handle changes and deletions as well as additions?
9. Are “exception” reports provided to tell you about any data import errors?


10. Can field names be easily customized to fit your terminology? (i.e., say a field name is “Alternate Phone” and you want it to read “Beeper” or “Cellular”; can the field name be easily changed?)
11. Can the tool bar icon description be customized?
12. Can the order of the plan output be customized for execution? (i.e., if you’ve determined you want your call list first, your list of critical applications by priority second, tasks and procedures third, etc., can you customize order of output?)


13. Is there a single-user version of the product that can operate on either a stand-alone PC or on a file server?
14. Is there a multi-user LAN version available?
15. In the multi-user LAN version, can multiple people access the same data table/file simultaneously? (i.e., does the system perform record level locking so that users A, B,
and C can all be in the employee database editing and/or printing at the same time?)
16. Does the LAN version operate in a number of LAN environments? (i.e., Novell, Banyon, Lan Manager, etc.)


17. Does the system have multiple levels of security?
18. Does the system require user ID/login security?
19. Does the system have recovery plan level security? (i.e., Finance can’t edit MIS’ plan.)
20. Does the system offer access security into different areas/functions of the tool? (i.e., can you can lock out some users from editing or printing plans, from performing any customization to product, from accessing administrative tools, etc.)
21. Can security profiles for various users be easily duplicated? (i.e., Users on the LAN have the same level of security, the only difference is the plan each can edit—one security profile can be created once and duplicated as necessary.)
22. Can a user be denied access to major data editing capabilities? (i.e., Move, Replace, Global Delete.)
23. Can an individual user change his/her password without requiring access to Security?


24. Does the system have an audit-history subsystem?
25. Does audit-history provide a before-and-after image of transaction performed? (i.e., does it show if this transaction was an add, a change or a deletion; if it was a change, does it show how the record looked before and after the transaction.)
26. Does audit-history identify/track the user performing the transaction?
27. Does audit-history stamp a date and time on every transaction?
28. Can the audit reports be printed?
29. Can you restore data from the audit-history subsystem?


30. Does the system interface to any Windows or DOS-based word processor? (i.e., you may or may not have standardized on a particular word processor - can the system be adapted to fit your needs?)
31. Can you use your own text documents instead of those included with the system?


32. Does the system come with standard reports?
33. Can you edit standard reports? (i.e., change the contents, style, and typeface.)
34. Are custom reporting capabilities available?
35. Can summations of equipment, supplies, employees, etc., be performed?
36. Can recovery plan data be sorted in any order? (i.e., alphabetically, numerically, ascending/descending, by zip code, etc.?)
37. Can you determine the search criteria for each report?
38. Can only portions of the plan be printed? (i.e., allows for the generation and printing of individual plan reports.)
39. Can reports be printed to the screen for online viewing before printing?
40. Can reports be printed or exported to a file?
41. If reports can be exported to a file, can the type of file be specified? (i.e., WordPerfect, Word, Lotus 1-2-3, Excel.)
42. If the type of file is specified, will the report be placed in the correct format? (i.e., will headers be placed in the header section of the word processing document.)
43. Can reports be sent directly through your MAPI e-mail system? (i.e., if you have the report on your screen, can you click a button and have it sent directly through your mail system?
44. Can previously created charts and diagrams be linked into your plan using OLE 2.0?


45. Is there hypertext help with the system? (i.e., can the user “jump” from one help topic to another.)
46. Is there context-sensitive help with the system? (i.e., when the user hits the Help key, does the system bring up help that is pertinent to the section or feature that was being used?)
47. Is there a “search” shortcut option under the Help menu bar so you can go directly to the help you need?
48. Is there an on-line “How To” Guide on building a recovery plan?
49. If yes, can this recovery planning guide be printed by each user?


50. Does the system offer flexibility in plan design? (i.e., even if system is based on a specific methodology...does it allow for variation and flexibility instead of rigid adherence to the plan’s methodology?)


51. Does the system have the ability to move information from one plan to another? (i.e., when employees change departments; can you easily move them into different plans?)
52. Does the system have the ability to “selectively” replace one employee’s team assignments and management positions with another’s? (i.e., if employee A is laid off or promoted, can employee B be easily assigned employee A’s responsibilities?)
53. When performing a global delete, are all relationships associated with that record also removed? (i.e., if a department is eliminated and you want to delete that plan, can you do a global delete of everything associated with that plan?)


54. Is the first year of maintenance services included with software?
55. Is the maintenance fee 15% or less thereafter?
56. Does vendor provide toll-free technical support within the U.S.?
57. Is toll-free technical support available 24 hours a day, 7 days a week to all users?
58. Is free training included with software?
59. Is free “hands-on” training available during evaluation stages?
60. Does vendor provide training for unlimited personnel at no charge?
61. Are product updates and enhancements free under active maintenance?


62. Can the vendor provide at least ten (10) references with contact names and phone number?
63. Does the vendor staff include Certified Business Recovery Planning consultants?
64. Is Business Recovery Planning software the Vendor’s principal line of business?

Dora Riano is employed with Strohl Systems.