The big debate: control compliance vs. risk management

When it comes to managing and mitigating technology risk, IT teams have traditionally relied on operational, control-compliance approaches focused on information security. The rest of the business, meanwhile, has probably adopted broader, business-focused risk management frameworks. This disconnect can sometimes inhibit IT leaders’ ability to effectively articulate technology risk to business stakeholders, which can impact investment decisions.

For effectively managing IT risk, there’s room for both approaches, because there are benefits found in each method.

Control compliance

One of the key benefits to a control compliance approach is the increased understanding and awareness gained regarding low-level control deficiencies that are present within the technology estate. As we can see from the various successful backdoor entries across industries, it is often an unpatched system or a minor configuration error that enables a hacker to gain entry. Therefore, a deeper understanding of current control deficiencies can increase the probability of detecting a small, exploitable vulnerability that can lead to a backdoor attack. 

In addition, by having a more formulaic assessment of controls (e.g., an assessment based on ISO 27001), there is less scope to miss out on the details. By using an industry best-practice framework to assess controls, there is at least the comfort of knowing that the controls assessed are those broadly required to protect certain security domains. Additionally, for less experienced risk managers, this methodology provides a secure base to work from and provides a certain level of guidance, at least in terms of security domains. 

I have seen these types of industry-recognized information security frameworks used as the basis for technology risk frameworks, which for me poses the question: What about the identification of controls that fall outside of the security landscape, and more importantly, the associated business risks? In my experience, a strict controls-focused assessment can miss the real risk exposure for the business. A very defined path also does not provide a way to identify new and emerging risks, as the risks have been decided upfront. 

Information security risks exist within every organization I have worked at. But they are not the only technology-related risks that the business faces.

My key concern regarding controls compliance as a technology risk management approach falls during the risk calculation phase, where an ineffective or missing control is automatically classified as a risk. In simple terms: no/ineffective control = risk. In my opinion this is entirely inaccurate, gives a false story to stakeholders, and is problematic as resources are then thrown at the “risk” that could be better used elsewhere to reduce risk for the firm. 

Risk management 

What would the effect be if operational risk within a technology department was calculated no differently to any other department within the firm? In the U.K., financial institutions calculate operational risk by using a risk and control self-assessment (RCSA) as outlined by Basel ii. An RCSA empowers the subject matter expert (SME) to self-define the risks that exist within their area, consider the operating effectiveness of the controls in place to mitigate against the defined risk, and then gauge the impact those controls have on overall residual risk. This is different from the control compliance approach in that the risk is considered first, then the operating effectiveness of relevant controls is taken into account, before defining residual risk. 

There are concerns from the controls compliance camp that the self-defined risks within the RCSA approach can create gaps in risk knowledge, as the risks are not predefined and originating from an industry control framework.  There is also the counterargument: Risks that have been defined by an SME and supported by a quality technology risk manager are likely to be most relevant to the firm and the technology department. 

In my experience, the RCSA approach provides a solid framework to challenge the risks and associated R/A/G (red/amber/green) statuses. The flexibility of an RCSA provides a basis for other risk management activities to feed into – such as risk events, problem management, and audit findings – and to ensure robust risk management is achieved. The result, based on the type of conversations that this encourages, is a far greater understanding of the real risk held within the technology department. 

For me, one of the greatest benefits provided by using an organization’s operational risk management framework within IT is that it is written in business terms. The technology risks are articulated in the same manner as every other department within the firm, and most importantly. This helps the Board and other key stakeholders better understand the technology-related information in front of them. This drives increased support and buy-in from the Board for key technology initiatives.

By contrast, presenting a series of low-level, ineffective controls to the board and classifying them as risks is too far removed from the potential negative business impact. To paint a picture: saying that 10 machines in X location are not patched is a very different story than saying business disruption due to malware risk has increased. The latter makes much more sense to people concerned with the welfare of the firm.

Hybrid approach: Using both methodologies to strengthen the overall result

As with most arguments, there are valid points on both sides. That’s why I believe that the technology risk manager should stick to the management of risk and the information security governance manager should stick to the application and governance of information security controls. 

Ensuring compliance with an industry-recognised information security framework provides great value to any organization. The responsibility for this lies with the information security team. The security team’s control compliance work should identify risk areas and feed into the overall RCSA document to inform information security-related risks and the operating effectiveness of the existing controls.  When information security risks are outlined in this context, any required remediation work is achieved at a program level, rather than piecemeal on a control-by-control fashion. Unauthorized access risk is out of tolerance? Then let’s initiate an identity and access management program to effectively address the risk. 

Information security is just one area of IT that can experience risk. What about the financial risks associated with running the IT department? What about the risk of ineffective change? 

While the information security governance manager is running a robust program to ensure appropriate application of controls within information security, the technology risk manager sits across the entire technology department, always asking the question, “What does this mean for the business?” Using an RCSA can help to articulate IT risks using the same language as the rest of the firm, making sure it all makes sense at the top.