Over the past few months we have explored together the various components of my GRC Reference Architecture. This embodies the technology end of my broader GRC EcoSystem – which to date has over 1300 technology providers, professional service firms, and content providers of GRC cataloged into the GRC market.
The components of the GRC Reference Architecture that we have looked at to date include:
- GRC Enterprise Data Architecture and Framework,
- GRC Enterprise Architecture Application Core, and
- GRC Business Process/Role Specific Applications.
Today we conclude the GRC Reference Architecture series with a quick overview of the industry, geographic, and technology views of applications aimed to help manage risk and compliance and broader GRC.
There are a variety of contexts for GRC initiatives within organizations. Some are focused on putting out specific fires, dealing with particular issues, meeting a requirement, or managing a solitary risk area. Others are focused broadly on driving agility, consistency, efficiency, transparency, and accountability across a range of GRC processes. This generates the demand for both enterprise GRC applications as well as business process/role specific GRC applications. This get’s further dissected into applications that aim to help organizations achieve compliance or manage risk in other areas such as:
- Industry specific issues. There are a range of solutions on the market that help specific industry verticals with the GRC related issues they face. In my analysis of the market and catalog of vendors you have dozens of technologies aimed at managing GxP compliance in life sciences, many focused on the complexity of managing credit/market/operational risk in financial services, there are a few focused on things such as Medicare/Medicaid RAC audits, even to the point of one vendor that manages compliance for car dealerships to state car sales laws. The point is that not every risk or compliance application is focused to solve every GRC issue for every industry. There are a variety of very specific GRC solutions aimed to help solve industry specific GRC issues. Even broad cross-industry GRC technology providers may have all the bells and whistles to help with industry specific issues – but they need to know what they are up against and how to solve client issues.
- Geographic specific issues. Another way to approach the GRC market is to understand the geographic reach of a vendor. There are vendors that have a very broad GRC solution that spans industries – but they only have language support or operations in specific localities. Further, there are GRC vendors that market and sell a solution for a specific geography to deal with laws and regulations, or to manage risk, within that jurisdiction.
Putting it together . . . with the GRC Reference Architecture you are able to map a vendor to what it provides for functionality – enterprise and/or business role specific as well as industry and geographic specific solutions. These work in harmony together to define what a vendor is about. One technology solution might offer enterprise GRC capabilities in risk, policy, and audit management but really is successful at selling into the IT role. Another vendor might have a very focused solution for dealing with Medicare/Medicaid RAC audits in health care within the United states.
The final way of looking at the GRC technology landscape through the reference architecture is to understand a solution’s technical capabilities. This involves understanding the technology building blocks that makes the solution work. Specific technology capabilities include the solution’s features for:
- Content management
- Process management
- Workflow management
- Survey & assessment management
- Collaboration management
- Project & resource management
- Business intelligence
- Dash boarding & reporting
- Business rule engine
- Enterprise application support
- Enterprise integration capabilities
- Learning & training management
- Security architecture
- Identity, role, and access management
- Storage & retention architecture
- Enterprise asset management
- XML & data feed integration
- Configuration & change management
- System log management
- Records management & Retention
This concludes our high-level look at the GRC Reference Architecture. I would encourage you to review the several related newsletters and blog posts and provide feedback as I put this into a written document to be published in the next month. You may comment on my blog or send me an e-mail.
The next step, besides publishing under the Corporate Integrity name, is to integrate this into the OCEG GRC Technology Blueprint which is in revision to be finalized with these changes in the next few weeks. This is meant to be a resource in framing the variety of GRC solutions on the market today and be a guide to vendors looking for solutions to their governance, risk, and compliance problems.
Beginning next week I turn the newsletter to a new topic of looking at the disarray of policies within organizations and ways to improve policy life cycle management and management.