is, to a large extent, governed by events that took place during systems

development. The most common of these problematic events

are:
■ Poor support from top management. Top management, even
today, is content in many cases to leave the development of new
and strategic systems to computer staff rather than being actively
involved. This means that, commonly, IT staff develop systems
with no management oversight and the systems become the IT
staff’s interpretation of what they believe management should be
looking for. This interpretation is not always accurate.
■ Poor staff attitude. Taking their lead from top management, the
users whose system it is from inception will also sit back in many
cases and leave the details to the IT staff. An attitude of nonownership
of the development process becomes prevalent.
■ Unclear business objectives. In many systems, the development
was triggered by a senior manager deciding “wouldn’t it be a
good idea if we had a system that would . . .” The system is then
developed to meet the requirements of a single manager rather
that the needs of the organization.
■ Management and users unsure of their needs. It is a common
occurrence that, when asked to express their needs for IT support,
management and users are unable to clearly articulate what they
require. Auditors find the same problem in asking managers to
explain how control is achieved. Think how difficult it would be
to explain to someone exactly how you breathe. You have done
it all your life, but would find it difficult to explain. It is part of
the job of the IT staff to uncover the users’ business needs and
translate these into potential computer support areas.
■ IT personnel unfamiliar with user needs. In many cases the IT
staff assigned to a given project have no fundamental understanding
of the actual business process to be computerized. Once
again this leads to misinterpretation of users’ wants and needs.
■ Additional user requirements not previously specified. A common
complaint of users is that “theStandards are much more specific than policies. These tactical documents lay out
specific steps
or processes required to meet a certain requirement. Table 2.1 shows the relationship of these
documents.
TABLE 2.1 Documentation/Level of Control
Level/Document Policy Standard Procedure
Strategic ✓
Tactical ✓
Operational ✓
As an example, a standard might set mandatory requirements that all company email is to be
encrypted. Although the standard does not specify how encryption is done, it does make clear
that encryption is a required activity.
In the procedural sense, a baseline is a minimum level of security. This is the absolute minimum
level that a system, network, or device must adhere to. As an example, an organization might
set a baseline password length at seven characters; although passwords can be longer, they cannot
be shorter than seven characters. Many times, baselines are usually mapped to regulatory
or industry standards.
The final document left for discussion is the guideline. A guideline points to a statement in a
policy or procedure to determine a course of action. As an example, the company might have
a guideline stating that IS audits are to be performed at least once a year. Other procedures
would detail how the audit should be carried out and what the audit should include. Guidelines
are frequently referred to as best practices. Guidelines