G R C, where did the S go?

Reposted, original on the “IT Governance, the Kapteyn’s view” blog on Computerworld UK in April 2009

The Blog post “To GRC or not to GRC, that is the question” looked at the integrated function of IT governance, risk and compliance (GRC) and why it is logical to combine these functions. The article ended with a question: “Why not integrate even more functions?” To answer that question we now look at integrating the ‘s’ of IT security.

IT security is often regarded as the dusty IT department living in the IT-dungeons. Concerned with the latest virus information and hack-attack news, it investigates how to adjust the firewall settings to minimize exposure to any such new threats. Basically, highly technical expertise, disconnected from the real world spending time thinking of things that users ‘should not do’ or things that ‘cannot be done’ because of security risks. And really how risky can it be if everybody does it? As always Dilbert has a brilliant character that portrays how many people see the security function and those associated with it. The character is called Mordac, the preventer of information services, which sums it up really nicely. As the saying goes, ‘there’s no smoke without fire’ so IT Security is probably (partially) to blame for this image problem.

Though this might be how the function is perceived there are forces at work to change this image and positioning. This new IT security function can be defined as ‘the function responsible for discussing the information risks with the information owner and designing, implementing and assuring the risk responses for the IT domain’. This definition suggests it is about informational risk management. It is about alignment with a stakeholder (the information owner) who resides in the business in most organizations. It positions the function not in the ‘IT dungeons’ but as an expert partner to the business information owner with knowledge and advice on how to safeguard the all important corporate information assets. This makes it part of the business IT alignment challenge we hear so much about. With new positioning and goal for the function it immediately becomes clear that integration with the IT GRC function should be considered. Instead of talking about the IT GRC function we might think about creating a GRSC function. There is one problem, we love our acronyms to have three letters; GRSC has four! Not to worry, we can apply a trick: Just rename IT Security as IT Operational Risk Management - this nicely distinguishes the new (existing) function from the dusty old image anyway. Now you can capture it under the ‘r’ from risk. A TLA again, problem solved. It works but in practice people tend to forget that security is supposed to be an integral part of such a GRC function. Furthermore, the security people feel unappreciated. So personally I would advocate giving security its rightful place under the sun and recognizing that in most organizations IT security was around before the GRC hype started. At the end of the day all these dust gathering activities will need to find their place in this new function (what IT security used to do wasn’t all that bad). Credit where credit is due: GRSC, Governance Risk, Security and Compliance.

I can almost hear it: “Why not leave well enough alone?” Let the security nerds play in there dungeons and I will create a nice new hype function called GRC. That sounds much better when I discuss the state of the world with my fellow management friends on the golf course or over a glass of Chardonnay. And indeed, you are right it is easier to explain. But be warned, you are heading for trouble and here is why. An important part of the work of the IT GRC function is to design, implement and assure control over the IT domain. To this purpose the function discusses the requirements of different stakeholder groups (IT-management, legal, financial etc.), combines the outcome and translates them in a set of controls for the IT domain. These (IT general) controls should be understandable and achievable for the different operational IT departments. Guess what, this is exactly what IT security (new style) will do. In some organizations a basic truth is forgotten: the security function should not invent security controls by itself, instead the security controls should be the appropriate response to the IT security risk as identified together with the information owner. Too often you will find a disconnection between IT security and the business owner of the information. IT security single-handedly decides what the security controls are for the IT functions. In these cases IT security might easily be perceived as ‘uninformed of the business requirements‘ and ’unwilling to work towards business requirements‘. If this is the case you should think about transforming your function into the new style anyway. When doing so you might as well integrate the IT GRC function in one go. When looking at the day to day tasks and activities of both functions there is much overlap. Integrating the functions offers the opportunity for efficiency improvement.

The next example shows the problems you might encounter if you keep two separate functions. It describes a real situation for an unnamed organization. The organization is subject to the Sox regulation and a couple of years ago it had to proof compliance for the first time. Organized by the finance department this resulted in a worldwide (business driven) program to achieve SOX compliancy. Since SOX has direct requirements for the IT domain the program also included a stream focused on this domain. Those involved with this stream noted that in the IT domain there already was another worldwide program to implement a new IT security standard (transforming the IT security function towards the new position as described above). Combining those two (control oriented) programs was considered but since both programs were on a very tight time schedule it was decided to leave them separate. From a project perspective this made sense and indeed both achieved their project goals. This is when the trouble started. Although for different regulations, both programs aimed for sustained compliance of the IT domain. So both functions independently created a run-and-maintain organization with the assignment to ensure continued compliance with their respective control framework. As a result IT operations had to comply with two different IT-control frameworks, each asking for different ways to prove compliance and both using audits as a means to double check. In practice this resulted in some (high-profile) IT shops being audited up to five times per year. For those on the work floor it was very clear that each auditor often asked the same questions. The time, effort and resources spent on assurance were considered unsustainable. So a new project was started to integrate the IT GRC and IT security function. However the IT organization, tired of anything to do with control, resisted the changes from the integration effort. Even though they were intended to improve efficiency and reduce the impact of the control requirements on the day-to-day operation. So what went wrong and how could it have been avoided? By the time programs were started (especially the SOX program) they were so urgent that any effort to integrate them would have caused unacceptable delay. Besides developing and implementing the SOX control framework, a new run and maintain organization was also created instead of transforming the already available (IT security) operational organization. The latter was considered too costly and time consuming to fit the SOX timetable. Furthermore the IT security function was already being transformed as part of the IT security program which complicated the issue. This newly envisioned run-and-maintain organization should have been in place before either program started. Basically the programs should have been in charge of describing what control objectives should be met - and by which section of the IT domain. The IT GRSC function should have designed the (integrated) IT control response in answer to those requirements. Given the nature of the IT security function at the time it was not considered capable of performing that role.

Looking at the current economic situation, it is foreseeable that a new wave of regulation is on the horizon (see the article “Weathering the financial crisis, other challenges for IT Governance are glooming on the horizon”). Though we do not know what the actual regulatory requirements might be it would be prudent to start building the (integrated) GRSC function. This way, once the requirements are known, the GRSC function has a clear view of the controls already in place and has the agility to react fast and appropriately to make the necessary adjustments. Last minute reactions under time pressure tend to be very costly. A timely investment in a fit-for-purpose IT GRSC function can start by looking at opportunities for efficiency improvement with current IT controls (thus creating an immediate return on investment) and will most likely pay for itself with the savings on compliance programs for future regulations. As Sun Tzu wrote in his classic on strategy (The Art of War): “Thus, though we have heard of stupid haste in war, cleverness has never been seen associated with long delays.”