The Challenge with Many Enterprise Controls

Thought leadership from Alyne CEO on why so many enterprise controls are still so bad. 

Organisations were first forced to think in the concept of controls in the wake of the Enron accounting scandal that not only brought down one of the largest energy companies in the U.S. but also the professional services giant Arthur Andersen. As a result the United States passed the Sarbanes Oxley Act requiring all public organisations listed in the U.S. to establish and maintain a regularly audited control framework to prevent collusion and fraud of the degree observed at Enron. After nearly two decades many organisations maintain control frameworks for not just for accounting relevant processes, but also for managing IT, cyber security, corporate sustainability and other areas. However very few are happy with them. Most control frameworks are overdimensioned, overburdened and not as effective as they could be. How did we get here?

 

I would like to start with addressing some common misconceptions around controls that are a contributor to poor control frameworks.

 

1. Controls are not failsafes

A control will not prevent all fraud from happening in a specific area of the control. A typical control is a 4-eye check on a certain process. This means a second person approves, confirms or reviews the decision of another. The obvious weakness in this control is that it becomes useless if the two people collude. A control therefore needs to be part of a consistent framework of evidence and management based practices that identify and prevent fraud.

 

2. Controls are not a compliance tick-in-the-box

If you have controls in your framework that you only consider a compliance “tick-in-the-box” exercise, this is likely not a good control. Establishing controls should always be in the interest of the management to keep financial harm from the organisation. Sure, you might not have the depth of controls in place were it not a legal or regulatory requirement. The intent of the control should however always be in the core interest of management.

 

3. Laws do not always define controls

They actually seldom do. I have seen “control frameworks” where the team has simply copied and pasted legal texts and have tasked the business with “complying” with these rules. Only very few laws or regulations actually define a useful control. It is up to an organisation to analyse the legal or regulatory requirement and deduct useful and effective controls to meet said requirements across affected processes.   

So why are we still ending up with horrible, unmanageable and expensive control frameworks? After being deeply involved with the control framework at many organisations I can identify some common culprits.

  

Common Culprits 

 

1. Design by committee

Often a control actually starts out in a reasonably useful state. Then many people are asked to review or contribute. It is understandable that many contributors will want to add an aspect specifically relevant from their perspective. Good control design is quickly thrown under the bus for the sake of approvals and sign-offs. The output are lengthy controls noting cases, exceptions, prose text and side notes. Building a control framework without a strong editorial process will unlikely be successful.

 

2. Risk First Approach

I know this might be controversial, as many standards suggest this approach, but I see significant issue with a “risk first approach”. The general principle is that you start with a baseline of risks that the business – or first line – determines. Then you identify which controls are necessary in order to mitigate these risks – thereby defining the control framework. A few issues: Where do the initial risks come from and how do you know when these are complete? How do you ensure that multiple risk owners are not defining redundant controls? What is with the controls that are not mitigating a risk but are required for regulatory or legal purposes? All of these shortcomings lead to huge, bloated and redundant control frameworks.

 

3. Framework Legacy

My final culprit is “framework legacy”. Essentially this describes the process of having controls in your framework that were added at some time, sufficiently agreed and audited multiple times. Often no one will have the authority or courage to question, refine or remove these controls. This means that over the past 20 years a control framework continuously grew.

 

At Alyne we have put a lot of thought into what makes a good control and came up with six key success factors:

 

Success Factors:
  • Specific - each control shall describe a specific action or practice that prevents harm to the organisation and its assets
  • Atomic - each control shall only define one specific aspect. Some poor examples of controls try to cover multiple aspects and end up covering half a page of text. If one answer cannot describe the current maturity or effectiveness, the control is not atomic. This also means that every control shall be meaningful by itself without the context of other controls.
  • Measurable - the effectiveness and design of each control shall be measurable. In Alyne, criteria and data points relevant to measuring the design and effectiveness of each control is always defined with the control to ensure this attribute.
  • Consistent in structure - while this is not always perfect, we strive to keep the sentence structure of each control consistent. Convoluded syntax such as double negatives or starting with subordinate clauses makes it much more difficult for the reader, assessor, recipient or other stakeholder to consume. This should be avoided at all cost.
  • Understandable - simply copying the text from a standard or law is not helpful. Wording in controls should be as simple and meaningful as possible to the audience within the organisation. Laws and standards need to be deliberately broad as to be generally applicable. Controls on the other hand shall only be focussed on your own internal organisation - and therefore use wording that is familiar and meaningful in that context.
  • Contextual - a control should provide a link to a standard, law or regulation and to risks it may mitigate. This context provides meaning to control deficiencies and enables more automated analytics.
Karl Viertel
Autor: Karl Viertel
About the author
Founder & CEO of Alyne, IT security professional, gadget enthusiast.