Where do controls come from?

As mentioned earlier, enterprises use controls to manage risks. Which is not very different from how we manage our personal risks, for example, the sensors on your garage door act as a control to make sure the door doesn’t close on someone’s head.

The one difference though is that while you may not have a documented catalog of controls you have in place in your household, organizations tend to document and formalize the controls they have implemented.

This formalization is needed for several reasons. As people in corporations move around, it is important to have institutional knowledge of the risk management measures in place. Also, regulators and auditors have an expectation that the organization has a clear idea of the controls it operates. Customer may expect and even demand they be shown evidence that controls are in place and are being run and managed effectively. That is because these customers may be critically dependent upon the organization for achieving their own goals, and therefore have an interest in making sure that the right controls are in place so that the services they rely upon are not impacted.

For an organization trying to organize technology risk from scratch, the question arises – where do controls come from? How does one get started with a list of controls that would be comprehensive enough to address most of the risks that need to be taken care of? Even if we intuitively know the real controls that matter that we need to have in place, for example, firewalls, backups, access controls, controlling changes to applications, segregation of duties etc, how do we organize them in a systematic way that allows us to be certain that we have covered the most important risks, and can methodically and consistently respond to regulators, auditors, customers, the Board, business unit CEOs and so on?

The answer to this question is not simple. That is because there does not exist a single listing or a templated set of controls that everyone could adopt. Yes, there are dozens of standards and frameworks in the public domain focusing on different types of technology risks. These have names such as NIST 800-53, NIST CSF, ISO 27001, COBIT, COSO, OWASP, CIS-Top-20 and several others. Each of these standards addresses a part of the puzzle, but not the complete story that is unique to an organization. So while enterprises may leverage several of these publications to determine the controls they need to have in place, ultimately the list of controls, or the “control catalog”, will be unique to the organization.

Let us think for a bit about how a company can decide what controls to have in place. Another important question to answer would be the control taxonomy. A control taxonomy is a classification structure, something akin to a tree showing the trunk to the branches, sub-branches etc, so categories of controls that are similar could be grouped together.

Process centric taxonomy

Often, the control taxonomy is organized around business processes. Which means you need to know what your key business processes are, and then identify the risks that could cause process failures. For each of these risks, list the mechanisms in place that would protect against the risks. These mechanisms are your controls.

So the thing works as follows: Processes have risks, and risks have controls against them.

The question arises: how does one know what business processes exist in the organization? Processes tend to be repetitive, use the same runbook, create an output for each “instance” of a process’s run, and so on. Often, identifying processes in a way that everyone would agree with can be challenging. Sometimes organizations would start with products – real things that their external customers are paying for – and start to think about the processes that are needed to deliver those products.

Function centric taxonomies

Though elegant in theory, using a process centric taxonomy can pose several challenges.