GRC became one of the really hot topics in business and IT, especially in larger organizations, over the course of the last few years. However, there is a lot of confusion about the terms associated with GRC. In many organizations, few people have a clear view of what GRC involves and requires, and few organizations have an organizational structure for GRC with clearly defined responsibilities. Of these organizations, many have limited their GRC initiatives either to some aspects like “business only”, “risk only” or “IT only”.
Virtually every organization has an IT security department. Few have clearly defined responsibilities for GRC (Governance, Risk Management and Compliance). But GRC is becoming increasingly important - and GRC approaches might be what help organizations in improving what they’re doing for IT security.
GRC became one of the really hot topics in business and IT, especially in larger organizations, over the course of the last few years. However, there is a lot of confusion about the terms associated with GRC. In many organizations, few people have a clear view of what GRC involves and requires, and few organizations have an organizational structure for GRC with clearly defined responsibilities. Of these organizations, many have limited their GRC initiatives either to some aspects like “business only”, “risk only” or “IT only”.
Very seldom will you find organizations that have a well-defined GRC strategy and roadmap, covering the organizational as well as the IT aspects of GRC, and supporting an evolution towards an integrated GRC approach including the organizational structures and processes, control frameworks, supporting technology and so on. Despite the current lack in that area, we clearly observe that GRC initiatives are maturing - however slowly. Like with most evolutions, beyond that “top-down” approach where frameworks like COSO and COBIT might be helpful guidelines, GRC also has to be understood at all levels of the organization. “Bottom-up” approaches are thus required using GRC principles and methodologies to improve the daily business in different parts of the organization.
One of the most logical starting points for bottom-up GRC approaches is IT security. IT security is still driven mainly from a technical perspective in most organizations. IT security experts are experienced technicians. But IT security is not a green field for technicians - instead it is a required element to support successful businesses. We are convinced that IT security can benefit from a GRC view through better focus and optimized investments.
Compliance and IT security
The most obvious link between IT security and the broad field of GRC is the “C” in GRC - compliance. There are many regulations that explicitly or implicitly require specific actions in the field of IT security. While several of the US regulations are more explicit, European regulations tend to be more implicit, frequently being filled by formal guidelines for auditors or specific practices of auditors.
Data protection and privacy laws are good examples of where IT security is in fact driven by regulatory compliance. Access to specific information has to be restricted. And IT security has to take action to ensure that part of regulatory compliance. But does IT security really know how to do that? To some extent, yes, but many employees in IT security departments are acting without explicit knowledge of the regulatory context of their actions. One might argue that this isn’t relevant as long as they are doing their job, and that it is the responsibility of management to ensure that regulatory compliance is met.
However, given that compliance is enforced by operative people it appears to be a good idea to strengthen the connection of specific actions in IT security and compliance requirements. Thus, the risk of failure and gaps will be reduced. People know the reason they are doing specific things and usually do a better job than the ones operating without that context.
Risk and IT security
Compliance is just one (and, from my perspective, minor) element in the relationship between GRC and IT security. Risk is far more important and - usually implicitly - something that has affected IT security since it’s very beginning. IT security is performed to mitigate risks, nothing else.
IT risks are tightly connected to business risks. Every IT risk is associated with a business risk. That might be cost risks for penalties, lost customer relationships, lost data or recovery. It might be performance risks with respect to the time-to-market, when applications aren’t ready in time. Every IT risk can be easily associated to related business risks. That’s particularly true for IT security. On the other hand, not every business risk is associated with an IT risk. That’s especially true for strategic risk, but also for some operational risks - the traffic jam which leads to a delayed supply of goods, and breaks in production, is at least only very indirectly associated with IT. But for most operational risks, there is an associated IT risk. The risk of abuse in trading on derivatives is directly connected to access controls and SoD rules or, from a risk perspective, the access or authorization risks.
The good thing with risk is that there are established methodologies, proven concepts and experienced people at least on the business side. The other good thing is that key concepts of risk management are easy to understand and therefore easier to adopt, for example, for IT and in particular IT security. There are many examples of KPIs or KRIs (key performance/risk indicators) that might be used as a foundation for defining risk controls in IT security. Beyond that it isn’t rocket science to describe IT risks and their relationship to business risks in a structured way. A few days in an intensive workshop should deliver significant results.
From IT security to information security
It might be a good idea to move a step forward and focus on information security. IT - information technology - is about information, and business is interested in information, not in technology. This means that information, not systems, should be in the centre of what is done. Is the information secure, regardless of where it resides? At rest, in transition, in use? Across different systems and even beyond the boundaries of the organization in case information is allowed to leave the (diminishing) perimeter of the organization? In fact, the question is whether information is at risk. And if we look at any regulation, it is about information, not technology. The transition from a technology-centric view towards an information-centric view has to be understood in the context of the broader evolution of IT towards more consistent approaches of information management.
In any case, when applying GRC principles it is a good idea to have an information-centric perspective and to define risk as “information risk” instead of “technology risk”. Information is the value for business, and information is at risk.
Risk as a key concept
Actions in IT or information security can be controlled using risk indicators. Risk indicators are metrics that show the level of risk and can be associated with other metrics like the potential business impact—and thus be valued. On the other hand, knowing risks allows you to identify actions (organizational or technical) to mitigate these risks. Based on the costs of these actions and the valued business impact, decisions can be made.
The first is always about whether it makes sense to mitigate a risk or not. Some risks are too expensive to mitigate or it is just impossible to mitigate them. In fact, that is the same decision when insuring yourself, but based more on facts (the KRIS, the business impact and so on) and felt risks than in personal life. Probably the best example for the limitation of risk mitigation is life insurance. They don’t mitigate the risk of dying; they only mitigate the impact on family and relatives. Beyond that basic decision the questions are about how to mitigate risk and what risks to mitigate in what order. Risk awareness in information security supports the decision making, starting from IT security strategies down to building the specific project portfolio. A risk ratio is probably the best criteria to decide about your strategy for information and, as the foundation, IT security.
Multiple layers of GRC
A big threat with all approaches that start partially top-down and partially bottom-up is to end up with a consistent solution. There is always the risk of having several incomplete, incompatible approaches at the end of the day. That’s even truer with GRC, where we have somewhat inconsistent technical approaches at several layers.
Starting at the top, there is what vendors claim to be “enterprise GRC”, with “enterprise” for “business”. The term “enterprise GRC” is wrong at least for most of these solutions because they cover only some aspects of the entire GRC topic - mainly some business controls with usually pretty limited ability to support automated IT controls. The latter are not only relevant for IT but for business as well - he most relevant information for the business is held in IT systems. However, most of these systems focus on manual controls which are of somewhat limited value - having a risk attested after the problem occurred isn’t sufficient.
The layer below might best be described as CCM (Continuous Controls Monitoring), even while there are several other terms used by vendors. Overall this level of GRC is about business process and business controls mainly, even while some tools might explicitly support IT controls as well.
The layer below are specific GRC tools for specific types of business applications, like the ones focussing on access controls in ERP systems or the growing market of tools for Access Governance. But there are several other tools which aren’t commonly understood as part of the GRC landscape. SIEM (Security Incident and Event Management) and IT Service Management tools (ITSM) are examples of this - tools which support the implementation of specific IT controls. That becomes obvious once you look, for example, at the broad range of controls defined in the COBIT standard.
The lowest level consists of specific tools at the system level which, for example, extract specific data for the higher level tools. When focusing on the relationship of GRC and IT security, the areas of SIEM and Access Governance are of particular interest.
While the notion of risk is part of several Access Governance tools, it is widely missing in SIEM tools. However, working on a consistent strategy which, over time, integrates the different layers of GRC tools definitely makes sense. Interestingly, there is currently only one vendor who at least started with such integration. The acquisition of Archer by EMC (the RSA division of EMC) will lead to some integration of an Enterprise GRC tool with SIEM solutions, hopefully complemented over time by other elements of the bigger GRC picture.
Focus on risk, focus on GRC strategies
From an IT management perspective, focus today should be on using risk as a key concept and building GRC strategies. IT security is something which is much better to manage when looking at it in the context of business risks. One short term impact will be that decisions about IT security investments can be made on a more solid foundation - and tactical investments (like many of the ones currently done in the DLP or Data Leakage Prevention space) might be reduced.