Designing Controlled Processes

By George Spafford

(Back to article)

In the mid-1970s, U.S. automobile manufacturers had to begin producing cars that met new emissions requirements that were aimed at curtailing pollution. In response to this federal mandate, they began layering emissions controls on top of existing engine designs.

They were able to meet the emissions guidelines but the engines lost power, fuel economy, were greatly complicated and prone to failure. As time went on, they responded to many pressures, including foreign competition, and began to design new engine systems that fundamentally incorporated the emissions controls as a design requirement from the outset.

Over the years, this systemic approach (meaning a holistic understanding of all requirements) and a continuous-improvement mindset has resulted in engines with fuel economy, power and reliability that far exceed pre-emissions engines.

Okay, so what does this have to do with computers, you ask?

There are many parallels to this story and the business environment within which organizations and their IT groups operate today. There are a great many regulatory requirements and security risks confronting organizations and, as a result, controlled processes are needed that integrate controls as part of the base requirements.

Processes are a collection of tasks assembled and ordered to achieve an objective. In other words, we design processes to accomplish something. Now, for each process there will be risks that threaten the attainment of the objective. Depending on how critical the objective is, controls can be implemented to reasonably safeguard the objective.

To illustrate, having nightly backups is a task we want to happen reliably. As a result of the critical nature of this process and the need to protect it, we may add controls such as reviewing the backup job log the following morning to look for any issues and take corrective actions.

A control to ensure that review is performed is to require a date and signature of the reviewing party. Another control is to perform periodic restoration testing to further validate that the backups are effective.

Thus, we can layer controls and add levels of assurance and costs until we feel that risks associated with the failure of nightly backups are reduced to an acceptable level.

With this in mind, the following questions are examples of inquiries that should be made to understand the design requirements of a controlled process:

  • What is the objective of the process?
  • What is the value of the objective?
  • What other processes are dependent on this process?
  • What are their values to the organization?
  • What other processes is this process dependent on?
  • What are their values to the organization?
  • What are the risks to the objective?
  • What risks are unacceptable?
  • For each unacceptable risk identify: a) probability of occurrence and impacts and b) mitigation options, their costs and the level of residual risk that will remain.
  • Then review the mitigation options and determine appropriateness:

  • Does the cost/benefit ratio makes sense?
  • What are the implementation costs?
  • What will the ongoing operational expenses be?
  • How will it impact productivity?
  • Can it realistically be sustained?
  • How long will it take to implement?
  • Will the mitigation activity itself be reliable? What are its risks? What controls are needed for it?
  • Many times, several lower cost controls can be combined to yield better risk reduction than one complex expensive control.

    It is essential that management support processes and set the proper “tone” so controlled processes are honored. Dr. Deming would emphasize there are only two outcomes to processes—you either follow them or formally change them.

    Process designs that embody proper controls can yield operational, security and regulatory compliance benefits. To be effective and efficient, they must be implemented on the basis of risk such that the controls used reduce the risks to objectives to an acceptable level.

    Risk mitigation beyond that point can result in needlessly expensive processes that are too complex for people to sustain in the long-term. Processes need to be designed with these requirements taken into consideration to yield not only controlled processes but, even more importantly, controlled processes that can actually be sustained over the long-term.

    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.