Operating and Security Standards for Mainframes, Open Systems, and Telecommunications (Part 3 of 3)
We conclude this series with more tips for IT managers who need to develop operating and security standards documents. By the end of reading this series, you should have created a handy "auditor’s checklist" of important items to include in your standards.
Quick Review
First, let’s review the main points from the two previous articles in this series:
- A standards document can be designed as an integral part of the disaster recovery plan. However, it’s better to build your standards completely separately from the recovery plan, because standards and disaster recovery deal with different—although related—issues.
- The standards document isn’t intended to be a list of emergency procedures. It’s designed to mandate changes in the day-to-day conduct of your business, in order to prevent disasters from occurring and/or to ensure that your recovery plan executes gracefully.
- The standards document should be written with the support and participation of all departments that will have to work with the final standards.
- Some standards apply equally to mainframes, open systems, and telecommunications environments. A good example is standards for wiring, such as the use of fire-retardant cable.
- Outside specialists are available who will work without a contract or any prearrangements, and will respond in the event that your equipment gets wet, burned, damaged by smoke, or sabotaged. Contact information for such specialists should be written into your standards document. Such preparations cost nothing, and using this sort of specialist occurs only after a disaster—presumably, after your business-interruption insurance kicks in.
Now that you’re back in standards mode, let’s consider the operational standards portion of your standards document. Operational standards include many of the changes you should be considering now in your working environment, to ensure that your recovery plan executes gracefully.