Confused About Controls?

In my recent chat with OCEG Fellow Brian Barnier, author of The Operational Risk Handbook, Brian noted "In talks I’ve shared, workshops I’ve taught, and client conversations over the past few months, I’ve been listening closely to struggles people have with controls. " Here's a summary of Brian's thinking on the topic of controls:

Brian Barnier: "Two causes for controls churn and confusion come to mind. First, the dog (control) does not bark if it fails to meet the tight assumptions required for control to actually work. For example, the “Chain of Fitness” assumptions for controls require that:

• The control is used as intended
• The control is maintained as implemented
• The control is implemented as designed
• The control is designed from the appropriate template
• The control template is appropriate for the process class and problem
• The control is located properly in the process flow
• The location in the process flow was determined based on the location of useful warning signs
• Useful warning signs were determined based on robust, real-world “What if?” scenario analysis
• Scenario analysis was conducted properly based on a thorough “know the business” understanding of environment and capabilities

Though still challenging, these assumptions are easier to meet when applied to retrospective financial reporting, when those reporting systems are stable and a threshold of materiality (percent of revenue or income) can be applied. These assumptions are more difficult to meet when a prospective view is needed of a dynamic, operational world, where a tiny issue can turn into a huge problem.

The second cause for controls churn and confusion is when the auditor or compliance person fails to bark because all looks well—because he or she does not understand the chain of fitness and other assumptions. There is a false sense of security."

I also find the way Brian summarizes the good, the bad and the ugly of controls very helpful. He says:

• “Controls” have so many definitions that people easily talk past each other. People rarely say they have a consistent definition beyond a small work team. So just the language is confusing.
• Despite the confusion, “controls” can be good when they are mechanical, consistent, and simple – they work like a light switch. Design that is simple so a control is easy to place in a process flow, install, maintain, and then each user interacts the same way and gets the same result. In other words, controls are in situations that are static, simple, and users are not stressed -- “same-old-same-old.” These situations tend to be typical compliance situations – highly defined. Well-designed controls can provide assurance against a set of criteria.
• Because many “controls” are in situations that are not static, simple, and unstressed, controls can be bad – especially when controls are called upon to manage the risk of a bad future situation, rather than comply with defined criteria. Good news, problems can be easily detected by auditing controls against the Controls Chain of Fitness, including control design, placement in a process flow, implementation at that point in the flow, maintenance, use condition and user range, and the tested use. Dangerously, too few audits follow a control “upstream” to check these conditions.
• “Controls” turn ugly when boundary conditions are exceeded for any step in the Controls Chain of Fitness. For example, a process change or a user under pressure. The exceeded boundary could also be a bigger change in the external environment of a control (new business partner with different transaction design or higher volumes flowing through a process) or external capabilities change (a “black hat” gets smarter or co-opts an internal auditor).

Brian has a lot of great insights, you can check out more and learn about his book on operational risk here: www.BrianBarnier.com