Operating and Security Standards for Mainframes, Open Systems, and Telecommunications (Part 2 of 3)

In part 1 of this series, Leo Wrobel examined how to start developing standards to help your business prevent disasters - and recover from them, if necessary. This article explores the physical standards that should be addressed in every business standards document: physical security, theft deterrence, fire prevention, and more.

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.