 |
 |
|
|
 |
|
 |
 |
 |
Newsletters
O'Rourke & Clark Accountancy Corporation
Supervisory
Committee Informer

From 1989 to 1991 I was a staff accountant for the auditing firm of O'Rourke & Clark, where I attained the required experience for my CPA license. All of the firm's clients were credit unions, so I had good exposure to auditing mortgages, consumer loans, credit card transactions, and similar personal banking activities. With my writing background, I also had the opportunity to work on the firm's newsletter, which regularly informed clients of topics like disaster planning.

For complete text, please download SUPERVISORY.doc (38KB)
Disaster Recovery Planning: The Time is Now (1991)
The Quake of '89 showed credit unions how dependent they have become on their information systems. Credit unions relearned that their databases are the most valuable asset they have -- and the most fragile. Even before they thought about their buildings, credit union managers wanted to know: What is happening to my systems? Will all my member and accounting data be there in the morning? Most credit unions came through unscathed -- some because they were well prepared, others because they were lucky. The next time disaster strikes (and it will not necessarily be an earthquake, or in Northern California), strong planning may make the difference between a nuisance and a tragedy.
Planning is the key element. Since natural disasters are inevitable, credit unions must design thorough, well-conceived plans to protect their data when their facilities are under Nature's siege. Additionally, such a program should encompass more common mishaps, like power failures or computer malfunction during business hours. While our discussion will center on in-house systems used by the larger credit unions (rather than on-line processing and manual ledgers used by smaller ones), the controls we will emphasize are common to all.
What should a disaster recovery plan include, and how should it be implemented?
The first task is to assign responsibility for the program to an individual or team. Their job will be to design, test, and continually update the disaster plan. To do it right, they must have a thorough working knowledge of the computer system and how data needs to be controlled. They will want to start by writing foolproof backup procedures that accomplish a complete system backup each night. The full day's business including member transactions, general ledger activity and all of the computer system's programming must be captured and then immediately taken off site for storage.
Don't wait until the following morning -- with Murphy's law at work, the one time evening tapes are left at the credit union will be the night of a fire. This holds doubly true, of course, for Fridays and nights before holidays. Tapes should always be carried in protective containers and stored where the risk of environmental damage is minimal. The tapes also should be tested periodically to ensure they are not damaged because of age or other factors.
In the event of a disaster, the tapes will be delivered to a data center that has a matching hardware configuration. The credit union will thus need to negotiate an agreement to access another EDP facility. These are generally of two types:
Hot Site: This is an EDP center having compatible hardware whose sole purpose is to be a backup system available for use by several credit unions or other businesses. A number of the major EDP vendors offer this option to customers utilizing their software.
Other Credit Union: An alternative is to establish a reciprocal arrangement with another credit union that uses the same EDP system and has a similar hardware configuration.
In either case, the credit union should obtain a written agreement that describes the procedures to be followed when the credit union needs to use the other EDP facility. A key part of any computer use agreement is a provision for routine tests that ensure the credit union's backup tapes can be processed on the backup computer system. Testing should be performed at least once a year.
In a reciprocal agreement with another credit union, testing may be difficult - even if the two use the same software vendor. They need to maintain similar hardware and coordinate the uploading of all software upgrades and enhancements. Failure to coordinate hardware or software changes may cause the systems to become incompatible.
We believe a system test should be conducted whenever either credit union alters its hardware or software. When testing the hot site, the same care needs to be taken to determine that your credit union data can be easily processed there. Routine changes in both hardware and software made by both parties should be strictly coordinated to ensure the systems are compatible.
With member and other key data apparently safe, let us focus on additional aspects of a disaster recovery plan. Hardware is less exposed than software, but still vulnerable if it is destroyed. You will want to have new equipment in place as soon as possible.
Each credit union should formalize an agreement with its hardware vendor to obtain new EDP hardware in the event of a disaster. This should include an itemized listing of all pieces of equipment, including part or serial numbers. One credit union attempting to recover from a recent disaster suffered an additional two-day delay because unique computer cables were unavailable from the vendor. The agreement should be in writing and constantly updated when the needs of the credit union change.
Credit unions should consider buying business interruption insurance. This would help compensate for direct costs incurred when the credit union could not operate. While this coverage will not prevent the loss, it will lighten the burden.
For complete text, please download SUPERVISORY.doc (38KB)
|
|
 |
 |
|
 |
 |
|
 |
|