SHARE

The Increasing Importance of IT ‘Controls’

Due to pressures for regulatory compliance, such as Sarbanes-Oxley section 404, plus needs for overall process improvement, there is a distinct push for controls in IT. Unfortunately, IT personnel in general are not versed in basic control theory. This article will briefly cover some basic concepts surrounding controls. Essentially, think of a control as a […]

Written By

George Spafford

Sep 1, 2004

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

Due to pressures for regulatory compliance, such as Sarbanes-Oxley section 404, plus needs for overall process improvement, there is a distinct push for controls in IT.

Unfortunately, IT personnel in general are not versed in basic control theory. This article will briefly cover some basic concepts surrounding controls.

Essentially, think of a control as a safety valve designed to prevent an accident. Organizations realize, either through trial and error, or by leveraging industry best practices, what to do and what not to do. Literally, processes, technology and people are put in place to “control” outcomes. There are three broad categories of controls to look at: Preventive, Detective and Corrective.

Preventive Controls

Preventive controls are aimed at avoiding an unwanted situation. Policies and procedures are good examples. The policy statement that “all changes will go through a formal change management process” highlights to the practitioner that changes are to be reviewed. Why? Because 80% of computer errors are related to human error and of those, a large majority could be caught if the proposed change had been formally reviewed, tested and a rollback plan been developed if the change failed. Thus, change management policies and procedures are aimed at preventing problems and, hence, are preventive controls.

An area that can fall under the heading of preventive controls is monitoring. All too often, monitoring efforts are viewed as detective control, which we will discuss momentarily, but the fact is that if a monitor is used to prevent an incident, then it is, by definition, a preventive control.

The first things many people think in response to hearing about preventive controls are, “Shouldn’t preventive controls be sufficient? Shouldn’t a good set of policies and procedures prevent the next accident?” Unfortunately, the short answer is “no.” Why? Because human nature is such that policies and procedures are all too often bypassed and/or misinterpreted for a whole number of reasons.

Detective Controls

As a result of human factors as well as environmental and security issues we need detective controls to alert us when an unwanted event transpires. Ideally, a detective control notifies monitoring parties as soon as possible, but it is after-the-fact.

Corrective Controls

Basically, corrective controls are aimed at restoring the system to its expected state. Having backup configuration files or hard drive images that can be reloaded to restore the state are both good examples.

Note that these two controls are predicated on an organization having effective change control and configuration management. Without these, an organization will have a difficult time restoring the state of the system because the last build may not match what was in production before the negative event occurred.

Automated and Manual Controls

There is a second dimension to consider as well — whether the control is manual or automated. Manual controls are things such as log sheets, review of log files, meetings and so on.

Some controls, such as meetings, need to be manual. However, there also are controls that best be automated because they are tedious or so voluminous that manual review is impossible. To illustrate, it is impossible to imagine someone sitting and reviewing every TCP/IP packet that came in over some period of time. That is best left to firewall log analysis applications to handle.

Relationship with Policies and Procedures

For those designing systems to manage the control framework, bear in mind that one control can spawn multiple policies and procedures. At the same time, one policy or procedure can relate to many controls. Thus, groups need to coordinate their efforts such that there aren’t duplicate efforts going on and/or contradictory policies and procedures developed. This complex web is one strong reason to centralize the management of the control framework even if IT itself is decentralized.

Policies and Procedures Alone Do Not Make a Control Environment

One last, but important, point — policies and procedures are only controls if they are designed properly and actually followed. All too often, management puts volumes of policies and procedures together, puts them on a shelf and tells people that controls exist. All that does is create “shelfware” that nobody bothers to follow.

There is a lot more to creating a control environment than simply authoring or buying a set of policies and procedures. The organization needs to understand them and actually follow them. At a minimum, that takes stakeholder involvement, communication, training, regular review of applicability and audits.

Summary

Controls are a combination of people, processes and tools that are put in place to prevent, detect or correct issues caused by unwanted events. The need is to create a carefully planned control framework that weaves the various types of controls together and protects the organization from risks.