Along the same lines, some control designs have shifted from simple towards being excessively complex.
These movements are being driven by a lack of understanding of internal control requirements and a large dose of fear relating to regulatory compliance. The fact is that all controls put in by IT, or any group for that matter, must be grounded in an understanding of the risks to the organization -- both within the operating unit, as well as holistically. Going overboard and putting in excessive controls can actually be detrimental for a variety of reasons.
To begin with a short review, internal controls are put in place to create a reasonable assurance that the goals of the organization are being appropriately pursued within the constraints of company mandates, regulatory requirements, and so on. Underlying this is the basic premise that controls exist to manage risk. By definition, to manage the organization's risks, you must first understand what risks confront the organization.
The lack of this rationale is what frustrated many IT people preparing for Sarbanes-Oxley. They wanted clear guidance that stated, ''Do this and your problems are solved.'' What IT needed to understand, and still do for that matter, was what risks confronted the organization's ability to have timely and accurate financial reporting. Once the risks were identified, the probability and impact of each risk event should have been decided and then unacceptable risks mitigated by implementing controls that lowered the risk's probability or impact to a level that was acceptable to senior management, notably the CEO and CFO.
It is very important to note that the goal is not to completely eliminate a risk. Instead, the goal of any effort to mitigate a given risk should be to reduce it to an acceptable level in the most cost-effective, efficient and sustainable manner.
To elaborate, the cost to the organization must be viewed systematically as the total cost to the entity, not just the purchase cost or the cost to IT. Shifting costs from one area to another is a misleading case of an over emphasis on local optimization.
Instead, the overall cost must be considered relative to the amount of risk reduction achieved. Additionally, the total costs and benefits must be considered not just at the point of implementation, but over time as well.
The control can not impact costs, operations and morale so significantly that it is impossible to follow over the long term unless it is formally identified as a stop-gap measure only. In those cases, people need to understand why it is being put in place and that it is for a limited period only.
Another aspect to consider is the level of complexity that is being added to the IT environment.
There are always complaints as controls and the related policies and procedures are added. Those complaints do decrease as the level of understanding as to why certain controls are needed increases. There is, however, also a point where the level of controls exceeds the team's ability to cope with them and get their job done. When forced between following controls and getting their job done, the tendency is to get the job done and/or have the error rate increase. In turn, the overall level of frustration skyrockets and increased turnover results. That would not a good situation to be in.
IT management must understand the risks and minimum set of controls needed to reduce the risks to a level acceptable not only to them, but to senior management as well. If the resources aren't available to reduce the risks to a level that is acceptable given the mitigation options available, then an awareness campaign needs to be waged for senior management to understand the situation. If sustainable solutions aren't funded, then the result will be risks that they must formally accept.
In order to be successful, IT must communicate the risks and compensating controls to ensure that the current levels of risk are acceptable. In cases where the level of risk exceeds acceptable limits and significant constraints are present, IT must work with senior management to address the limiting factors.
Conversely, in areas where the level of risk is acceptable, then additional controls should not be added. In fact, if unnecessary controls exist, they should be carefully analyzed and removed.
Controls are needed, but moreover, the appropriate level of controls commensurate with the risks is what IT groups need -- no more and no less.