In response to a variety of needs including process improvement and regulatory compliance, organizations develop controls and processes. Many times they are aimed at preventing an error from happening again or are designed to enable the attainment of objectives.

Okay, good. The problem is the environments within which organizations operate foster a constant need to evolve. If processes are not updated, then they can slow or even halt progress and create organizational conflict. The problem we are discussing is compound.

At one level, controls are developed and instantiated in the relevant processes. The resulting processes are indicative of management’s intent in terms of objectives that must be met and risks that must be minimized at a given point in time. For example, management may require that all requests for access be reviewed and approved by the controller, IT security and the requesting manager for proper scrutiny.

These reviewers are then reflected in the design of the access management process. Over time, the firm grows and the controller no longer knows everyone, their roles and at some point begins to simply approve all requests rather than delay the process. The point is at some point the control and process design should have evolved.

On another level, people need to perform their jobs. Processes that hinder them from accomplishing their jobs are problematic. It may be that a given policy was valid five years ago but viewed as pointless now. This puts employees in a predicament. On one hand they need to get their job done and on the other they have to follow policies. The response to the conflict will vary depending on the policy in question, organizational culture and the individual.

Some will bypass the process entirely. Some will take the imitative to alert management that the process should be reviewed. There are even some that will continue to comply for whatever reason. Unless steps are taken to review and update the process, the outcomes will likely be suboptimal in terms of productivity and even generate audit findings that must then be dealt with.

A Time to Review

To avoid these problems, organizations need to create a process to review controls and processes. The first step is to define the triggers for the reviews. The base trigger is to formally define a review interval for the various policies and the underpinning processes and procedures. Some groups will have a marathon review period each year. Others will have rolling scheduled reviews throughout the year making the load more manageable.

A second trigger is major incidents. A review should be conducted after each crisis to learn if the policies, processes and/or procedures need to be revised. If so, then a request for change should be submitted, the necessary changes should be made and then submitted for review and approval through the Change Management process.

A third trigger is when there is recognition that there a new risk or regulatory compliance requirement that impacts policies, processes and procedures. Again, the changes should be handled through the Change Management process.

A fourth trigger could be the change management process itself. When changes are evaluated, their impacts to controls and process design must be reviewed as well and if changes are needed, then requests for change (RFCs) should be launched accordingly.

In response to a variety of needs including process improvement and regulatory compliance, organizations develop controls and processes. Many times they are aimed at preventing an error from happening again or are designed to enable the attainment of objectives.

Okay, good. The problem is the environments within which organizations operate foster a constant need to evolve. If processes are not updated, then they can slow or even halt progress and create organizational conflict. The problem we are discussing is compound.

At one level, controls are developed and instantiated in the relevant processes. The resulting processes are indicative of management’s intent in terms of objectives that must be met and risks that must be minimized at a given point in time. For example, management may require that all requests for access be reviewed and approved by the controller, IT security and the requesting manager for proper scrutiny.

These reviewers are then reflected in the design of the access management process. Over time, the firm grows and the controller no longer knows everyone, their roles and at some point begins to simply approve all requests rather than delay the process. The point is at some point the control and process design should have evolved.

On another level, people need to perform their jobs. Processes that hinder them from accomplishing their jobs are problematic. It may be that a given policy was valid five years ago but viewed as pointless now. This puts employees in a predicament. On one hand they need to get their job done and on the other they have to follow policies. The response to the conflict will vary depending on the policy in question, organizational culture and the individual.

Some will bypass the process entirely. Some will take the imitative to alert management that the process should be reviewed. There are even some that will continue to comply for whatever reason. Unless steps are taken to review and update the process, the outcomes will likely be suboptimal in terms of productivity and even generate audit findings that must then be dealt with.

A Time to Review

To avoid these problems, organizations need to create a process to review controls and processes. The first step is to define the triggers for the reviews. The base trigger is to formally define a review interval for the various policies and the underpinning processes and procedures. Some groups will have a marathon review period each year. Others will have rolling scheduled reviews throughout the year making the load more manageable.

A second trigger is major incidents. A review should be conducted after each crisis to learn if the policies, processes and/or procedures need to be revised. If so, then a request for change should be submitted, the necessary changes should be made and then submitted for review and approval through the Change Management process.

A third trigger is when there is recognition that there a new risk or regulatory compliance requirement that impacts policies, processes and procedures. Again, the changes should be handled through the Change Management process.

A fourth trigger could be the change management process itself. When changes are evaluated, their impacts to controls and process design must be reviewed as well and if changes are needed, then requests for change (RFCs) should be launched accordingly.

In response to a variety of needs including process improvement and regulatory compliance, organizations develop controls and processes. Many times they are aimed at preventing an error from happening again or are designed to enable the attainment of objectives.

Okay, good. The problem is the environments within which organizations operate foster a constant need to evolve. If processes are not updated, then they can slow or even halt progress and create organizational conflict. The problem we are discussing is compound.

At one level, controls are developed and instantiated in the relevant processes. The resulting processes are indicative of management’s intent in terms of objectives that must be met and risks that must be minimized at a given point in time. For example, management may require that all requests for access be reviewed and approved by the controller, IT security and the requesting manager for proper scrutiny.

These reviewers are then reflected in the design of the access management process. Over time, the firm grows and the controller no longer knows everyone, their roles and at some point begins to simply approve all requests rather than delay the process. The point is at some point the control and process design should have evolved.

On another level, people need to perform their jobs. Processes that hinder them from accomplishing their jobs are problematic. It may be that a given policy was valid five years ago but viewed as pointless now. This puts employees in a predicament. On one hand they need to get their job done and on the other they have to follow policies. The response to the conflict will vary depending on the policy in question, organizational culture and the individual.

Some will bypass the process entirely. Some will take the imitative to alert management that the process should be reviewed. There are even some that will continue to comply for whatever reason. Unless steps are taken to review and update the process, the outcomes will likely be suboptimal in terms of productivity and even generate audit findings that must then be dealt with.

A Time to Review

To avoid these problems, organizations need to create a process to review controls and processes. The first step is to define the triggers for the reviews. The base trigger is to formally define a review interval for the various policies and the underpinning processes and procedures. Some groups will have a marathon review period each year. Others will have rolling scheduled reviews throughout the year making the load more manageable.

A second trigger is major incidents. A review should be conducted after each crisis to learn if the policies, processes and/or procedures need to be revised. If so, then a request for change should be submitted, the necessary changes should be made and then submitted for review and approval through the Change Management process.

A third trigger is when there is recognition that there a new risk or regulatory compliance requirement that impacts policies, processes and procedures. Again, the changes should be handled through the Change Management process.

A fourth trigger could be the change management process itself. When changes are evaluated, their impacts to controls and process design must be reviewed as well and if changes are needed, then requests for change (RFCs) should be launched accordingly.

Note: audit findings are triggers but there is an important distinction to understand. Audits serve to validate that a process works and look for ways to improve but the audit is not part of the process. It is a better to have review triggers in place rather than waiting for audit to discover deficiencies.

One potential avenue is to take the triggers and define events in Event Management for proper handling. This newly defined process in ITIL v3 can help with the correct processing of these events when they happen.

To assist with the proper management of these combined documents, they should be managed as configuration items (CIs) in the configuration management system (CMS). The benefit of doing this is that they can be related to one another. The system can show what controls relate to what processes and what procedures roll up to what processes. In turn, these can be related to the IT services and business services. Thus, when there are changes in the environment it is easier to understand what needs to be reviewed.

In addition, by tracking controls, processes and procedures as CIs, key attributes can be tracked. This could include review date, relevant regulations, who own the document, who needs to sign off, date put into production, and so forth

In closing, organizations need to understand what controls and processes are needed to mitigate risks and achieve objectives. As time goes by, the environment the organization is in will evolve as will the organization itself. In response, the controls and processes will need to change as well. It is best to plan in advance to understand what triggers should initiate control and process reviews as well as a fixed time when they should be reviewed as well and see if they still reflect organizational needs.

George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George's professional focus is on compliance, security, management and overall process improvement.