Evolution Of New GRC

While GRC is ultimately about collaboration and communication between the business roles and processes responsible for varying risk and compliance functions, there is no doubt that technology has an important role in facilitating this enterprise cooperation.

 I have put together a new high-level framework addressing GRC and its components.

• Enterprise GRC Architecture/Applications. Represent the solution areas that span risk and compliance roles and processes that organizations can leverage and use as the backbone for a GRC strategy. The technology categories in this area are listed below in brief definition. These solutions are not locked to a single role but something multiple roles/business functions/processes can leverage. I feel this area is fairly solid
• Role specific Applications. This provides a list of GRC related roles within the organization and specific application categories that serve these specific roles. There is still much to be built out in this area and would appreciate your feedback on these specific roles and the application categories that serve them. There are some technologies, such as audit management, that are essential for a strong GRC strategy - but they serve primarily a single role, audit.
• Industry Specific Applications. It is in this category that applications/technologies aimed at a specific industry vertical are mapped. An example is the several technology providers aimed specifically at helping life sciences companies comply with GxP. Or there are other solutions aimed at Medicare/Medicaid RAC audits. Or NERC in the utility space. This area has a lot that can be built out. I would love your feedback on getting to a standard for representing industries that is not too narrow nor broad. I would also appreciate your feedback and experience on applications focusing on specific industry issues.
• Geography/Legal Jurisdiction Applications. This is the most rough, and I am not sure how it will be built out. This is the thought that there are specific legal jurisdictions that might require a specific solution for GRC purposes. Thoughts?
• Technology Architecture Components. This is a listing of feature/functionality that any given product in any of these areas might bring together to deliver a solution. It also may represent the IT platform/architecture tools that organizations can build their own GRC platforms out of if they were not going to invest in a commercial product. As for commercial products, a buyer should be able to evaluate them and identify if such technology components as content management, workflow, and other components are part of the platform being implemented/considered. Of course, varying GRC related solutions (and there are over 500 vendors and 1000+ products in this space) can be utlizied in a variety of technology delivery capabilities such as software as a service, hosted application, or traditional software model.

Now to give you some brief definition to the Enterprise GRC Architecture/Applications, and again I request your feedback and input, they are as follows:

• Accountability Management. This provides an enterprise platform to manage the accountability/ownership of risks, controls, policies, incidents/loss, and GRC related processes. Every silo of risk and/or compliance should have someone accountable as well as specific policies, investigations, loss, risks, assessments, etc.
• Assessment & Survey Management. This is the enterprise platform for delivering a common assessment and survey tool/process. Of course, at a basic level this could be spreadsheets - and often are. At the right implementation level it is a consistent tool to deliver, track, and record survey/assessments for risk, control, and compliance purposes.
• Asset/Process/Entity Register/Taxonomy. If you think about it - every risk, control, policy, loss, requirement applies to something in the organization. It is important that organizations have an ability to model their organization structure, roles/employees, business relationships, processes, physical environment, logical environment, and information. From there - risks, controls, policies, and so forth can be applied to the assets/processes they apply/belong to.
• Continuous Control Monitoring/Automation/Enforcement. This is the category to provide an enterprise platform for the continuous monitoring and automation of controls - both preventive and detective. This includes continous/automated monitoring of (1) IT infrastructure, (2) application permissions, (3) records/data, and (4) business transactions.
• Control Registry/Taxonomy. It is here that the organization provides a catalog of its controls, as well as versioning of controls to provide a history/audit trail. It is in this category that the broad spectrum of controls is defined and managed.
• GRC Dashboard & Reporting. This is the core capability necessary to analyze and report on the breadth of GRC related data across the enterprise.
• Hotline/Helpline. It is here the organization deploys a centralized web-reporting and/or call center where employees, clients, partners, stakeholders can report wrong doing and/or suspicious activity as well as seek help on certain compliance, risk, ethics, and code of conduct topics.
• Identity & Access Management. My research this past year has caused me to elevate this to an enterprise issue, and not just an IT risk and compliance category. Organizations need an enterprise approach to cataloging identities, access, entitlements to both the physical and logical business environments. If you think about it, a lot of risk and compliance issues comes down to who has access to what, what can they do with it, etc.
• Investigations/Incident/Loss Management. This represents an enterprise platform/ability to consistently document and manage the process/workflow of investigations. It also provides a common platform for tracking and monitoring losses the organizations has experienced.
• Policy & Procedure Management. It is here an organization builds/delivers a solution to provide a consistent interface and user experience to manage the development, approval, communication, maintenance, and archiving of corporate policies and procedure documents. This also includes training management related to those policies and procedures.
• Requirements Register/Taxonomy. It is in this category that organizations document and breakout the specific chapter and verse of regulatory, legal, and standard guidance. This is the registry that defines the mandatory and voluntary boundaries by which the company is governed - it defines the lines that should not be crossed and what is required of individuals, processes, business relationships, etc.
• Risk & Regulatory Intelligence. Organizations need the ability to monitor the internal context of risk and compliance as well as the external context that business operates within. This represents the category of technologies that can take information from data feeds and turn them into tasks/workflows routed to the right individual to make a decision on a changing business, risk, and/or regulatory environment and how it impacts the organization.
• Risk Analytics & Modeling. Some might see this as part of GRC dashboards and reporting, but the area is complex and can stand on its own. This represents the organizations ability to display and model risk. At a simple level it is heatmaps, at a complex level it may involve monte carlo simulations, bayesian modeling, or value at risk.
• Risk Register/Taxonomy. This represents the enterprise catalog of risks. Like the other register/taxonomy items above the purpose is to not only define, but also to cross-reference risks to loss, policies, controls, assessments, etc.