Criteria and Methodology for GRC Platform Selection

More than a decade ago, the acclaimed management philosopher Peter Drucker stated, “the diffusion of technology and commodification of information transforms the role of information into a resource equal in importance to land, labor and capital.”¹ The exponential growth of information after the Internet boom of the 1990s shows the accuracy of his foresight. In today’s world, the fortunes of most organizations are tied to the information they possess and the sophistication with which they are able to manage it. As a consequence, 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.²

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. Selecting a GRC platform is a complex endeavor, though, and requires extensive collaboration among business, IT, compliance and audit. It requires a substantial investment of time and effort in addition to the capital investment required for purchasing and maintaining the platform. Making the task of selecting a platform even more complex is the fact that this space is populated with a large number of competing products—AXENTIS, MetricStream, OpenPages, Paisley, Modulo and Archer, to name a few. Thus, it is imperative that the platform selection is done intelligently, to ensure positive return on investment (ROI).

The following sections provide comprehensive criteria that can be used to evaluate and select a GRC platform for an enterprise. These criteria have been determined through interviews with experts in different industry segments, examination of industry best practices, the experiences in evaluating GRC platforms for multiple enterprises and the use of requirements engineering techniques. They can be used as building blocks to which the unique requirements of the organization can be added to arrive at a complete set of requirements that need to be considered. While they are being defined here for GRC platforms in totality, they can easily be adapted for tool sets addressing individual areas of governance, risk or compliance. The criteria are structured in three major sections: general considerations, functional requirements and nonfunctional requirements. How to use the criteria to arrive at a decision is described further through a scoring model and a case study.

General Considerations

The criteria are general in nature and applicable to all enterprises, irrespective of regulations applicable to them, their size or the business sector in which they operate. These are must-haves and, hence, are generally used for exclusionary purposes, i.e., to narrow the field of proposals that would be considered. Figure 1 summarizes the parameters and artifacts that can be used to evaluate vendors against the criteria:

• Cost—GRC solutions can vary significantly in cost. While considering cost, it is important to consider the total cost of ownership (TCO). Some important TCO components are hardware, implementation and consulting fees, training, customization, maintenance, security, and operational costs. Also, this is a useful metric to have for ROI calculations.
• Vendor reputation—With the growing popularity and demand of GRC platforms, a significant number of vendors have jumped into this space. In addition to there being a surfeit of genuine vendors, the picture is further clouded by some vendors that market GRC solutions that are thinly disguised versions of their existing product suite targeting a different space. As competition heats up and market forces weed out weaker players, only the stronger players will survive. Hence, it is important not to get stuck with a solution that might become unsupported in the future, either because the vendor has ceased to exist or because it has exited this space. This can be accomplished through a thorough appraisal of the vendor’s installed base, references and financial viability.
• Product scope, strategy and vision—Threats and vulnerabilities are ever changing. The recent financial meltdown is leading to a change in regulatory landscape. All of this is a stark reminder that GRC is an ongoing process that might require an expansion of scope. Another driver for this is the fact that many countries are still working toward maturing their regulations and compliance regimes— J-SOX³ being one such example. Finally, as organizations enter new market segments, they have to adapt to GRC requirements in that space. All of these factors mean that it is important to examine the product scope, strategy and vision to make sure that the vendor has a long-term view of its product offering and has mechanisms to adapt and expand as the landscape changes. Product road map and research and development (R&D) strength (measured in terms of R&D head count and investment) are some examples of how to further this examination.

Functional Requirements

Functional requirements are used to define the behavior of the target software, including features and capabilities that determine what a system is supposed to accomplish. The following sections define high-level requirements for each of the three principal components—governance, risk management and compliance—as well as for other general functionality:

• 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.”⁴ In light of this definition, it is clear that the governance component of the GRC platform must be evaluated for the requirements presented in figure 2.
  
  
• 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.⁵ Figure 3 presents the high-level requirements for risk management.
  
  
• Compliance—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. Figure 4 presents the requirements to ensure that these needs are supported by the GRC platform.
  
  
• Vendor oversight—Regulators are increasingly focused on personally identifiable information (PII) and how organizations manage such data among vendors that have access to the data. For example, healthcare providers to most organizations have access to PII. They require organizational due diligence to ensure that their vendors have mature information security practices to protect their data. GRC platforms should facilitate this effort. Support for shared assessments, the industry standard for determining the maturity of information security practices at a vendor, is one way a GRC platform can demonstrate its strength.
• Workflow—A good workflow engine is essential to the success of a GRC platform. Given the large number of areas and users involved in the GRC platform, there is a need to manage and distribute work and monitor its progress through all of these steps.
• Document management—GRC platforms are used for organization and management of an extensive body of documentation. In addition to policies, standards and procedures, they are used for housing organizational controls, tests conducted to verify the robustness of these controls and custom attributes. Therefore, strong document management features are essential to success.

Nonfunctional Requirements

Nonfunctional requirements are used to define the operation of the system or the environment in which the software should run. Since the spectrum of nonfunctional requirements is very large, the field has been narrowed to the requirements that are most applicable to the selection of a GRC platform:

• Security—GRC platforms house critical information about the security posture of the enterprise, including information about vulnerabilities, risks and data as well as their classification. The consequences of a security breach are great and include exploitation of vulnerabilities, damage to credibility, financial loss and legal liability. As such, strong security measures should be provided in the platform to enforce not only protection from external breaches (e.g., through encryption), but also from insider misuse of information by allowing enforcement of the two fundamental principles of security: least privilege (i.e., individuals should have just enough permissions and rights to fulfill their roles) and need to know (i.e., individuals should have access to specific information only if it is essential for them to carry out their roles).
• Scalability—The amount and the complexity of information resources within organizations are increasing at an exponential rate. In addition, it might be necessary for organizations to scale their GRC platform for new risks and compliance regimens. This could be necessitated by their foray into new market segments, expansion of their global footprints making them subject to local regulations, or new regulations coming into existence. Determining scalability requirements appropriately upfront provides flexibility for future growth. Because scalability is based on future needs, it requires a certain amount of prediction and estimation to plan for it. An examination of the strategic business plan of the organization for the next few years might provide this insight.
• Interface—To achieve maximum efficiency from the GRC platform, it is important that it provide interfaces for integration with enterprise applications used to drive business processes (e.g., integration with an identity management system or configuration management database [CMDB]). This will help automate data collection, controls and processes and, hence, simplify analysis, reporting and remediation.
• Usability—Usability requirements specify the ease of use of a system. Given that a GRC platform would be used by a broad spectrum of users including business, IT, audit and compliance, it is important that their input is sought in evaluating the usability of any platform under consideration. The five parameters that should be considered for this purpose are ease of learning (evaluated through training and documentation provided), task efficiency (efficiency of the system for frequent users), ease of remembering, understandability and subjective satisfaction.⁶
• Support—Supportability deals with the ease of customization to meet the unique needs of the organization, incorporation of new features or enhancements, and bug fixes. A good example of a supportability requirement is, in the case of an organization that has to adhere to Payment Card Industry (PCI) standards, the GRC platform vendor should provide updates when the new versions of PCI get released. Maintenance, updates, consulting services and customization are some areas to consider when evaluating vendors against this dimension.

Example Selection Process Walk-Through

The criteria presented previously can be combined with a weighting mechanism to arrive at a decision on which GRC tool to select. An example case study is presented here.

A medium-sized retail organization is looking to strengthen the governance and risk management of its information. It has been classified as a tier-2 vendor for PCI. In addition, it offers pharmacy services in its stores and, hence, has to be compliant with the US Health Insurance Portability and Accountability Act (HIPAA). It has budgeted TCO of US $750,000 for a GRC solution to manage these efforts for a five-year period. It is not looking to include US Sarbanes-Oxley Act compliance in the ambit of this GRC tool because it intends to continue leveraging its existing point solution for that. The following is a step-by-step description of how the organization arrived at a decision using the criteria defined previously (figure 7 shows the results of these steps):

1. It created a request for proposal (RFP) defining the GRC needs of the organization and invited vendor responses. Based on exclusionary criteria, it narrowed the vendor choices to A, B and C.
2. It partitioned its stakeholders into primary (those who are directly impacted by the platform choice) and secondary (those who are intermediaries in the selection process) stakeholders. Its primary stakeholders were office of the CISO, IT, internal audit and pharmacy process owners. Its secondary stakeholders were vendor management, the business continuity planning (BCP) team and finance.
3. It identified its other requirements, primarily using the requirements solicitation questions, shown in figure 5 (also included in figure 7 under “Other Requirements”).
   
   
4. It weighted all criteria on a scale of 1 to 5 (see figure 6). (Note that since this article focused on identifying essential requirements in the previous sections, most of those would be weighted 3 or more; when unique organizational requirements are added, the spread from 1 to 5 would likely be observed). Figure 7 reflects the weights along with explanations where the choice of a weight is not obvious.
   
   
5. It created a committee drawn from primary and secondary stakeholder teams. For vendors still under consideration, this committee rated them against each requirement on a scale of 0 to 5, using consensus method (some stakeholders chose to recuse themselves on occasions, as they were not knowledgeable about the requirement under consideration). A vendor should be disqualified if it has a score of 0 on any criteria rated 3 or above (i.e., any criteria of significant interest to the primary stakeholders). The following were used as raw data to arrive at a decision:
   • Vendor demonstrations
   • White papers, spec sheets and other documentation
   • Data from research organizations such as Gartner, Forrester and Burton Group
6. It computed a total weighted score for each vendor. Since the scores of vendor A and vendor B are close to each other, it had those vendors bid against each other to reduce costs and ended up choosing vendor B as a result.

Conclusion

Businesses are increasingly relying on GRC platforms to achieve synergies across governance, risk and compliance. In the crowded landscape of GRC platforms, arriving at the right choice for an enterprise is a complex decision. It is imperative that all applicable criteria are considered to ensure positive return on investment (ROI). It is also necessary to make the evaluation process as objective as possible.

The proposed approach helps facilitate business and IT in understanding the essential criteria to consider when evaluating GRC platforms. In addition, it illustrates how these criteria can be rolled into a scoring model to arrive at an objective decision. This ROI-driven approach will improve an organization’s ability to select the right GRC platform that fits its need and, in turn, will help it manage the complexities associated with GRC efficiently.

Endnotes

¹ Drucker, P.; Management Challenges of 21st Century, Harpers Business, 1993
² Hagerty, John, et al.; “The Governance, Risk Management and Compliance Spending Report, 2008-2009: Inside the $32B GRC Market,” www.amrresearch.com
³ Uehara, K., et al.; “J-SOX Challenge: Efforts to Comply With the New Japanese Regulation,” Information Systems Control Journal, vol. 5, 2008, p. 34-37
⁴ IT Governance Institute, Board Briefing on IT Governance, 2nd Edition, 2003
⁵ Stoneburner, Gary; Alice Goguen; Alexis Feringa; Risk Management Guide for Information Technology Systems, Special Publication 800-30, National Institute of Standards and Technology (NIST), 2001
⁶ Lauesen, Soren; Houman Younessi; “Six Styles of Usability Requirements,” Proceedings of REFSQ’98, Presses Universitaires de Namur, 1998

Authors’ Note

The authors would like to thank Greg Handrick, R&D manager at Boston Scientific, and Kim Pender, security compliance manager at Target Corp., for reviewing the article and providing valuable feedback and suggestions.

Anand Singh, CISM, CISSP
is a senior consultant with extensive background in information security and compliance, as a practitioner and a researcher. He specializes in IT risk management and its use as a decision-support system to determine the economics of security investment. He is a highly sought-after speaker on information security issues. He can be reached at anand.singh@gmail.com.

David J. Lilja, Ph.D.
is the Louis John Schnell Professor and head of electrical and computer engineering at the University of Minnesota in Minneapolis (USA). He also serves as a member of the graduate faculties in computer science and scientific computation, and is a fellow of the Minnesota Supercomputing Institute. His research interests include security, computer architecture and performance analysis. He has been elected a fellow of the Institute of Electrical and Electronics Engineers (IEEE) and a fellow of the American Association for the Advancement of Science (AAAS). He is the author of the book Measuring Computer Performance: A Practitioner’s Guide.