Selecting the right GRC solution for your organization
The latest issue of the ISACA Journal (volume 1, 2010) has an excellent article on “Criteria and Methodology for GRC Platform Selection” by Anand Singh (an experienced senior consultant in IT risk management) and David J. Lilja, Ph.D (Professor at the University of Minnesota). I commend this to everybody interested in solutions for their organization’s GRC processes. Unfortunately, access to the Journal is limited to subscribers. The good news is that ISACA has given me permission to quote from the piece. (ISACA membership is worth the price of admission.)
I like a lot of what is in the article, but there are also points where I disagree or would expand the discussion. In this post, I will attempt to draw those out in a way that helps people looking to acquire software for GRC.
By way of background, Singh and Lilja say: “governance, risk management and compliance (GRC) issues around information have become central to organizational strategies. Investment in these areas has been increasing steadily, topping US $32 billion in 2008, a growth of 7.4 percent over 2007”. The numbers are from an AMR report by John Hagerty.
They continue: “GRC platforms provide a single, federated framework that integrates organizational processes and tools, supporting those processes for the purpose of defining, maintaining and monitoring GRC. An appropriately chosen GRC platform can lead to reduced complexities and increased efficiencies.” This is a little idealistic, as most (including Forrester Research and Corporate Integrity) recognize that no vendor has solutions for every single GRC process. However, the ideal of a single technology framework, preferably one that is common with other enterprise applications (such as the ERP) is commendable and one I share.
The trouble is that the authors don’t really define what they mean by GRC. As I have blogged previously, there are many different ideas on what GRC means and what functionality is included. At first, they appear to take the larger, more holistic view when they define what they mean by each of governance, risk management, and compliance.
“Governance—The IT Governance Institute (ITGI) defines governance as “the set of responsibilities and practices exercised by the board and executive management with the goal of providing strategic direction, ensuring that the objectives are achieved, ascertaining that the risks are managed appropriately and verifying that the enterprise’s resources are being used responsibly.”
“Risk management—Risk management is activity directed toward assessing, mitigating (to an acceptable level) and monitoring risk. The principle goal of an organization’s risk management process should be to protect the organization and its ability to perform its mission, not just its IT assets.
“Compliance is an increasingly complex task given the global footprints of organizations, the increase in regulatory environment (which is likely to become even more stringent given the opportunities exposed by the current economic crises) and local regulations.”
However, when the authors list the functionality that should be assessed by the potential buyer, they only include a few items under each category. For example, under governance they list (a) the ability to align governance with business objectives; (b) policy, standard, and procedure management; (c) the ability to enable oversight through reporting mechanisms; and, (d) information for decision support. They don’t mention potential governance requirements around code of conduct dissemination and training, a whistleblower hotline, management of board briefing and discussion materials, investigation management, and management of the internal audit function.
The authors appear to recognize this when they provide a list of questions that can be asked to help understand the potential buyers’ functionality needs.
What is your biggest GRC area of concern?
- What compliance regulations are applicable to your area?
- Have you failed any areas of compliance audits in the past? If so, what were the findings?
- What improvements would you like to see in your current mechanism for prioritizing the security budget?
- How do you rate the effectiveness of your security controls?
- What would you like to see in the reports indicating the current status of compliance?
- How do you evaluate your risk currently? What are possible areas of improvement?
- What are critical threats to your area?
- How many times have you experienced these threats in the past 12 months?
- What area are you more concerned about, insider abuse or external threat? Please provide specifics.
- Have any of your end users expressed dissatisfaction with the extra steps they have to go through because of the security controls?
- Do you have a good data classification mechanism?
These are all good questions. I would change the ones that are IT-focused (such as questions 4, 5, 11, and 12). But the very first question is the most important, critical question:
What is your biggest GRC area of concern? What are the business problems you need to address, in what priority?
This is what I suggest.
- Do not be persuaded by a vendor or service provider’s definition of GRC, which is typically based on the specific products and services they offer. Instead, understand that GRC processes are extensive; they are how an organization is directed and managed to achieve goals, considering risks to achievement, and complying with applicable laws and regulations.
- Instead, define the needs you have in your organization for automation. The author’s questions are a good start to identifying them.
The rest of the article is sound (with one exception, which I will explain shortly). Singh and Lilja suggest and provide guidance on considering:
- Cost, with an emphasis on the total cost of ownership
- Vendor reputation
- Product scope, vision, and strategy
- Other factors (such as workflow and product security)
They also provide a useful example of how one company made its decision, using weighted assessments for each criterion.
Now to the final point of disagreement: The article lists a few vendors of GRC solutions. However, they omitted a major player: SAP. In a future blog, I will discuss how SAP provides solutions (and there are several) that enable efficient and effective GRC processes. If you want to know more now, please let me know.