Operating and Security Standards for Mainframes, Open Systems, and Telecommunications (Part 2 of 3)
- Developing Your Standards
- Standards that Everyone Can Use
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
We continue this month with the second of three articles providing tips for developing your own operating and security standards. By the time you’ve finished reading this series, you’ll have a handy "auditor’s checklist" of the common items to include in your standards, and some not-so-common issues that you may have overlooked.
Developing Your Standards
A standards document can be designed as an integral part of the disaster recovery plan, but my recommendation is to have the standards completely separate from the recovery plan, for essentially two reasons:
- The disaster recovery plan should be as lean a document as possible, making it easy to understand in the event of a disaster. Maintaining such leanness is difficult if the document is cluttered with numerous standards.
- The standards document is not intended to be an emergency procedures list; instead, it’s designed to mandate changes in the day-to-day conduct of a business. Stated another way, standards are the changes you make to the daily operations environment: a) to prevent disasters from occurring; and b) to ensure that the emergency procedures you have in the recovery plan will be executed gracefully.
In many ways, the standards document is the conceptual foundation for the recovery plan. Think of your standards as the foundation, justification, and support for the emergency procedures you’re implementing.
Because the standards document should be written only with the support and participation of all affected departments, your company may want to consider forming an "Operating and Security Standards" committee. This group, consisting of perhaps a dozen members, would be tasked with determining very broad company-wide issues such as which vendors, software, and equipment the company will support. Consider these reasons:
- Absent an "official" listing of supported services and vendors, it becomes all too easy for end users to subscribe to or purchase every type of service and equipment available. This lack of control spreads the technical services departments very thin as far as knowledge level and support services are concerned, since it’s impossible to be 100% proficient on everything. The answer lies in sticking to approved and supported systems that are maintainable, but that also don’t stifle productivity.
- Bear in mind that the support limitations just mentioned can present a severe drain on resources in a disaster, when technical support departments must scramble to restore innumerable systems and software packages at a recovery center or alternate work location.
- Admittedly, the end user needs flexibility in order to be productive and make money for the company. Therefore, you also don’t want to be too rigid in your standards of supported software and services. It’s all a question of tradeoffs, and that’s why I recommend setting up a committee.
- The standards committee provides a forum for users to introduce new technologies, and for these technologies in turn to be evaluated by qualified technical people in terms of costs, benefits, and organizational drain on resources. From the technical perspective, it’s impossible to get too close to your customer. If there’s a hot new technology that revolutionizes productivity in the workplace, you had best learn how to provide it; otherwise, your internal customers will get it elsewhere.