GRC Reference Architecture: the GRC Enterprise Application Core
Friend,
Last week we began our presentation of the GRC Reference Architecture, which is part of my broader GRC EcoSystem (which includes over 1300 technology, professional service, and information providers). The GRC Reference Architecture is the core to the revisions to the OCEG GRC IT Blueprint – for those of you interested in the OCEG Technology Council we will be reviewing this architecture, the changes to the GRC IT Blueprint, and upcoming projects via a 2 hour web conference on November 13th (contact me as I chair the OCEG Technology Council).
The GRC Reference Architecture is comprised of: information model/framework, enterprise core GRC application(s), role/business function specific applications, as well as industry and geographic/jurisdiction specific applications.
In the previous posting we looked at the heart of the enterprise GRC information model and framework. This provided a high-level conceptual on the different data areas that interrelate with each other to form the enterprise core of GRC. The core of the GRC Information Model and Framework relates core GRC libraries of information across the organization, including the objective, risk, control, event, responsibility, policy, requirement, and enterprise (business model) libraries.
This week I provide the outline of the enterprise GRC core applications that interact, share, and leverage the information model to deliver sustainable, consistent, efficient, transparent, and accountable GRC processes. To be an application at the enterprise core of GRC requires that the application be used across the business as a platform that touches and interacts with a variety of business roles and information. This provides the foundational application(s) that make deliver on the GRC philosophy of a common architecture and collaboration across business roles and interests.
There are dozens of application categories that fall outside of the enterprise GRC application core – those are the ones that are focused on specific business roles and functions (e.g., quality, EH&S, matter management). We will look at a framework for those next week.
The enterprise GRC application core consists of the following applications:
- Strategy, Performance, & Objective Management. This is the missing application link of GRC. So many GRC applications focus on the downside – avoiding the bad – that it fails to relate to the upside of why organizations take risk and maintain control: business performance and optimization. Governance is about directing the organization on a specific course, risk is taken to achieve objectives, and compliance is there to stay within boundaries so the organization does not get off course. A successful GRC application is going to integrate business strategy, performance, and objective management to provide context to risks, controls, policies, and assurance. GRC applications need to be a fundamental part of corporate performance management systems.
- Risk Management. Risk management applications come in all shapes and sizes. Most are very niche focusing on specific business risk areas such as market, commodity, security, and other risk areas. However, at the enterprise GRC core is the application that brings all the silos of risk scattered across the business together to form the foundation of an enterprise risk management (ERM) system). This is the system that defines the organizations risk library (risk taxonomy) and is the central system for doing risk assessments/surveys, identification, analysis, treatment, ownership, modeling, and monitoring of risks across the enterprise. The risk management system interacts with corporate performance systems to map key risk indicators to key performance indicators. It provides the consistent engine to communicate and assess risk across the business.
- Audit & Assurance Management. The role of audit is central to GRC. While audit and assurance management can easily fit into a specific business function/role application used by internal audit, it is necessary that it be part of the enterprise GRC core. Audit interacts with all parts of the business (at least it should) to provide assurance that the organization is staying within the boundaries of policies and control that management has defined. The audit management platform becomes core to GRC as it provides audits to all aspects of the business and its relationships and gives other business roles a place to interact and comment on their thoughts to audit findings. The audit management platform delivers resource scheduling, calendaring, work paper management within a consistent application and framework. Audit management systems should leverage and use the same information libraries of risks, controls, policies, objectives, and even events that other GRC roles are using as part of the audit process.
- Event & Case Management. It is unfortunate – organizations are in a complete disarray of how they manage investigations, issues, incidents, events, cases (or whatever other synonym that works best for your business area). As a result the organization lacks any good source of understanding losses and issues across the organization. An organization cannot do good risk management if it does not know what the history of losses and materialized risks have been. Events also trigger where policies are ineffective, out of date, or not understood. They also identify where controls are not working – or where further controls are warranted. Organizations need a central library of managing events and cases across the enterprise. This application area focuses on consistent documentation and management of events – from reporting, to managing and documenting the investigation, to recording the loss and business impact. NOTE: I am working on a published research piece to be available in December on Event & Case Management systems which will provide an overview of several applications in this space.
- Policy & Procedure Management. Similar to Event & Case Management, how organizations manage policies and procedures is out of date and ineffective. Organizations are quick to drop policies into a SharePoint site where they have no management in place to govern them. In my policy & procedure audits I have found organizations with dozens of policy publication sites and manuals. Many with out of date policies that lack policy owners and have not been reviewed for meeting the organizations needs in years. Further they are often written with different language and formats – without a thought to a corporate standard for style and language. When you ask about policy exceptions – the organization has no idea how many have been granted. Policy management and communication is a core area of defining corporate culture and values, it is also where the company can quickly get in legal and regulatory turmoil if done in an ad hoc manner. Organizations need policy management systems to manage the lifecycle of policies from ownership, development, approval, communication, exception management, periodic maintenance, and archiving. Part of this involves the ability for any role in the organization to login and see which policies relate to their job, what policy
training and attestations are required, and what testing/quizzing needs to be done. In the day of YouTube I am seeing demand to deliver policies and associated training within the same environment – particularly as more and more laws are being written that require training and understanding of requirements and compliance. Policies relate back to risks as they establish the risk culture and tolerance of the organization, they relate to helping the organization meet objectives by staying within boundaries of control, they relate back to events which identify where policies have been violated . . . you get the picture. NOTE: I will be approaching a published research piece on the components and vendors delivering Next Generation Policy & Procedure Management in February.
- Compliance Management. Compliance is a confusing word as it has different meanings and connotations (as with Risk and Governance). Elements of compliance management can be found in all of the other application areas – policy and event management are both central to a good compliance program. This particular domain of compliance management is the assessment engine to deliver surveys and self-assessments across the business and its relationships to understand and report on the state of compliance and control within the organization. It links to the policy and control libraries to build compliance assessments and delivers these to the business in a consistent interface across the organization. It is separate from audit management as audits are the independent validator of compliance while the compliance management application is management’s tool to make sure it is staying within mandated and voluntary boundaries of control.
- Control Monitoring, Automation, & Enforcement. Related to compliance management is the world of compliance and control automation. The goal of this suite of GRC applications is automate the validation and enforcement of controls within business processes, systems, and information. This encompasses an array of solutions that deliver control monitoring, automation and enforcement across business transactions, configurations of business systems and applications, segregation of duties, and validation of master data records. While many applications in this space have been focused in niche areas (e.g., SOX SoD), Corporate Integrity is seeing growth and expansion of this technology to be enterprise applications across risk and compliance areas.
- GRC Dashboards, Reporting, Analytics, & Modeling. It is this area that provides the reporting glue across GRC domains. The GRC enterprise application core requires a central hub that integrates all of the information into a common interface to deliver metrics, dashboarding, reporting, and measurement of GRC activities across the business. It is here the organization looks to deliver the command and control center for GRC activities.
The enterprise GRC application core provides the foundation of GRC across the business. All of the applications referenced are ones that can be leveraged from one side of the business to the other – providing a consistent approach to GRC across silos of risk and compliance. However, there are a variety of business functions and roles that have their specific needs that demand applications aimed for their business function. Next week we will take a look at the application categories aimed at specific business roles and functions that plug into the broader GRC Reference Architecture.
Detailed training on the GRC Reference Architecture can be found in Corporate Integrity & OCEG’s GRC Strategy & Technology Bootcamps.