Designing Controlled Processes

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.